Dovrei usare Mutex O sezione critica per Windows Mobile RIL

Question

Radio livello di interfaccia (RIL) API native in Windows mobile applicazione . In questa API, i valori restituiti / risultati della maggior parte delle funzioni non sono restituiti immediatamente ma vengono fatti passare attraverso una funzione di richiamata che viene passato alle API RIL.

Alcuni esempi di utilizzo sono disponibili all'indirizzo XDA develompent Strumenti e Google Gears geolocalizzazione API .

La mia domanda è, in questi due esempi, un mutex viene utilizzato per custodire i dati al posto di altri oggetti di sincronizzazione.

Ora, farà sezione critica fare bene qui nei casi d'uso descritti da entrambi gli esempi? Quale thread o processo sarà effettivamente richiamare le funzioni di callback?

Modifica
I miei dati si accede da miei codici solo dall'interno mio processo, ma quale thread / processo sta chiamando le funzioni di callback in RIL API? Cioè, passai una funzione callback per l'API RIL, ma sono i callback richiamato da altri processi? in tal caso, darà un'altra spiegazione perché i campioni stanno usando mutex. Se l'API RIL in realtà crea un thread all'interno del mio processo e chiama le mie funzioni di callback, allora penso sezione critica andrebbe bene (ed è più veloce di un mutex).

Aggiornamento:
Ho i dati che è (1) si accede dai miei codici da dentro il mio proprio processo ed è anche (2) modificato da una funzione di callback. La richiamata è fatto da RIL API.

La mia domanda: quale thread / processo sta chiamando le funzioni di callback in RIL API?

La storia finora:
Me:. Ciao Mr RIL, si prega di mettere un po 'di dati nel mio ufficio (a.k.a variabili)
RIL: OK Sir. Io metterò i dati più tardi e vi segnalerà quando è fatto (io ho usato un evento qui).

è necessaria una carta di accesso per entrare nel mio ufficio. Se il signor RIL è dalla stessa azienda come me, il signor RIL può utilizzare la propria carta di accesso per entrare nel mio ufficio (nel mio caso, significa una sezione critica). Se è da altre società, ho bisogno di creare una scheda carta di accesso / visitatore per lui (nel mio caso, ho bisogno di un mutex qui).

Se il signor RIL utilizza la propria carta di accesso, significa che non ho bisogno di creare una scheda carta / visitatore l'accesso per lui e questo significa meno problemi per me. (Vale a dire sezione critica è più veloce di un mutex)

Il problema è, ho appena incontrato questa Mr RIL un paio di giorni fa e non so molto di lui. Non so se è dalla stessa società come me. Una possibilità come menzionato da nobugz è per impostare una scheda di accesso per il signor RIL a prescindere se il sig RIL è dalla stessa società come me. In questo modo, il signor RIL è garantito per essere in grado di entrare nel mio ufficio. (I miei dati / variabili sono garantiti per essere sicuri)

In questo momento io uso mutex nel mio codice (impostare una carta di accesso possibilmente ridondante per Mr RIL).

Aha! Appena ricevuto un'idea durante la scrittura di questo. Penso che basta chiedere Mr RIL da quale azienda che è. In questo modo, non c'è bisogno di configurare carta di accesso per lui in futuro, se si scopre di essere nella stessa azienda come me. (Cioè mettere GetCurrentProcessId() e GetCurrentThreadId() nella funzione callback)

Answer 1

Il Windows Mobile RIL risiede normalmente in Device.exe (per WM6.x). Tuttavia, quando il processo invoca l'RIL, la chiamata passa attraverso il RIL Proxy.

Il proxy RIL è collegato con, e risiede nel vostro processo, e gestisce tutte le questioni connesse con i limiti del processo per voi (come un a parte, questo è almeno in parte la ragione per cui tutte le strutture di dati RIL devono essere imballati in un unico blocco di memoria di dimensioni note). Internamente la RIL proxy crea un thread su cui viene eseguito il callback.

Questo significa che il codice può utilizzare un oggetto CRITICAL_SECTION per fornire la necessaria sincronizzazione / protezione.

Answer 2

Il punto di usare il mutex è che non si sa che cosa filo potrebbe fare la richiamata. Sì, una sezione critica avrebbe funzionato troppo. Attenzione, sbagliare provoca casuale e molto difficile da diagnosticare guasti.

Answer 3

Una sezione critica è un mutex. Una sezione critica è diverso da un mutex normale (almeno principalmente) in un modo:. È specifico di un processo, in cui un mutex può essere utilizzato in processi

Quindi, in questo caso, la domanda di fondo è esattamente quello che si sta proteggendo - se si tratta di dati all'interno del vostro programma, che non saranno accessibili a un altro processo, poi una sezione critica dovrebbe fare il lavoro bene. Se si sta proteggendo qualcosa che sarebbe stato condiviso dai due processi se l'utente dovesse eseguire due istanze del programma in una sola volta, allora probabilmente bisogno di un mutex.

Modifica: Per quanto riguarda il dover utilizzare una sezione critica per proteggere ciò che fa RIL per sé, no, che non è (o almeno sicuramente non dovrebbe ) essere necessari. Con un mutex, si sta contando su tutti i processi cooperare con l'apertura di un mutex con lo stesso nome per controllare l'accesso alla risorsa condivisa (s). Non si può contare su questo, quindi se è necessario l'interfaccia è completamente rotto.

Aggiornamento: a meno che non stanno facendo qualcosa di veramente insolito in RIL, la richiamata avverrà entro il vostro processo, quindi una critica dovrebbe essere adeguato. Se si tratta di modificare i dati, questo significa che i dati sono mappati e visibile a quel codice - il che significa che i dati nei dati nella sezione critica anche essere mappato e visibile, e funzionerà. Il tempo di una sezione critica non funziona è quando hai a che fare con processi separati, in modo che i dati in uno non è mappato / visibili agli altri.

Answer 4

Bene, un altro differenza tra un mutex e una sezione critica (implementazioni di Windows, ovviamente) è che una sezione critica è rientrante -. Vale a dire lo stesso thread può acquisire la sezione critica per due volte, senza dover rilasciare