Soll ich Mutex oder kritischen Abschnitt für Windows Mobile RIL verwenden

Question

Ich bin mit Radio-Layer Interface (RIL) Natives APIs in Windows mobile Anwendung . In dieser API werden die Rückgabewerte / Ergebnisse der meisten Funktionen sofort nicht zurückgegeben, sondern werden durch eine Callback-Funktion übergeben, die an das RIL-API übergeben wird.

Einige Verwendungsbeispiele unter XDA develompent Tools und Google Gears Geolokalisierung API .

Meine Frage ist, in diesen beiden Beispielen wird ein Mutex verwendet wird, um die Daten anstelle von anderen Synchronisationsobjekten zu schützen.

Nun wird Critical Section tun gut hier in den Anwendungsfällen von beiden Beispielen beschrieben? Welcher Thread oder Prozess wird die Callback-Funktionen eigentlich nennen?

Bearbeiten
Meine Daten durch meine Codes zugegriffen wird, nur aus meinem Prozess, aber der Thread / Prozess die Callback-Funktionen in RIL-API ruft an? Ich meine, ich verabschiedete eine Callback-Funktion an den RIL-API, sind aber die Rückrufe von anderem Prozess genannt? in diesem Fall wird es eine andere Erklärung geben, warum die Proben Mutex verwenden. Wenn das RIL-API tatsächlich schafft einen Thread in meinem Prozess, und es ruft meine Callback-Funktionen, dann denke ich, Critical Section wäre in Ordnung (und es ist schneller als ein Mutex).

Update:
I-Daten haben, was (1) zugegriffen durch meine Codes aus meinem eigenen Prozess und ist auch (2) aus einer Callback-Funktion geändert. Der Rückruf von RIL-API durchgeführt wird.

Meine Frage: Welcher Thread / Prozess der Callback-Funktionen in RIL-API ruft an?

Die Geschichte bis jetzt:
Me. Hallo Herr RIL, bitte einige Daten in mein Büro setzen (a.k.a Variablen)
RIL: OK Sir. Ich werde die Daten später legte, und ich werde Sie signalisieren, wenn es fertig ist (ich ein Ereignis hier verwendet wird).

Eine Zugangskarte benötigt, mein Büro zu betreten. Wenn Herr RIL von der gleichen Firma ist wie ich, Herr RIL seine eigene Zugangskarte verwenden kann, mein Büro zu betreten (in meinem Fall bedeutet es, einen kritischen Abschnitt). Wenn er von anderen Unternehmen ist, muss ich eine Zugangskarte / Besucherkarte für ihn einzurichten (in meinem Fall, ich brauche einen Mutex hier).

Wenn Herr RIL seine eigene Zugangskarte verwendet, bedeutet das, ich nicht eine Zugangskarte / Besucherkarte für ihn einrichten müssen und das bedeutet weniger Probleme für mich. (Das heißt Critical Section ist schneller als ein Mutex)

Das Problem ist, ich traf ihn nur Herr RIL vor ein paar Tagen und ich weiß nicht viel über ihn. Ich weiß nicht, ob er von der gleichen Firma wie ich ist. Eine Möglichkeit, wie erwähnt von nobugz ist eine Zugangskarte für Herren RIL einzurichten, unabhängig, ob Herr RIL von der gleichen Firma wie ich ist. Auf diese Weise wird Herr RIL garantiert der Lage sein, mein Büro zu betreten. (Meine Daten / Variablen sind garantiert sicher sein)

Im Moment benutze ich Mutex in meinem Code (eingestellt auf eine möglicherweise redundante Zugangskarte für Herren RIL nach oben).

Aha! Ich bin gerade eine Idee, wenn dieses Schreiben. Ich denke, ich werde nur Herr RIL fragen, von dem Unternehmen, das er ist. Auf diese Weise muss ich für ihn in Zukunft nicht einrichten Zugangskarte, wenn er dreht sich in der gleichen Firma wie mir erwiesen. (Das heißt put GetCurrentProcessId() und GetCurrentThreadId() in der Callback-Funktion)

Answer 1

Die Windows Mobile RIL befindet sich normalerweise in Device.exe (für WM6.x). Wenn jedoch Ihr Prozess die RIL aufruft, Ihr Anruf gelangt über den RIL-Proxy.

Die RIL-Proxy mit, gelinkt und befindet sich in Ihrem Prozess und Griffe alle Probleme im Zusammenhang mit Prozessgrenzen für Sie (Nebenbei bemerkt, ist dies zumindest ein Teil der Grund, warum alle RIL Datenstrukturen müssen verpackt werden in einen einzigen Speicherblock bekannter Größe). Intern wird das RIL-Proxy erstellt einen Thread, auf das Ihr Rückruf ausgeführt wird.

Das bedeutet, dass der Code ein CRITICAL_SECTION Objekt verwenden können, die notwendige Synchronisation / Schutz zu bieten.

Answer 2

Der Punkt des Mutex zu verwenden, ist, dass Sie nicht wissen, was Thread könnte den Rückruf machen. Ja, ein kritischer Abschnitt würde auch funktionieren. Vorsichtig, bekommt es falsch Ursachen zufälliger Reihenfolge und sehr schwer Versagen zu diagnostizieren.

Answer 3

Ein kritischer Abschnitt ist ein Mutex. Ein kritischer Abschnitt unterscheidet sich von einem normalen Mutex (zumindest überwiegend) in einer Art und Weise. Es ist spezifisch für einen Prozess, in dem ein Mutex können über Prozesse verwendet werden

Also, in diesem Fall ist die grundlegende Frage genau, was Sie zu schützen - wenn es die Daten in Ihrem Programm ist, die zu einem anderen Prozess nicht zugänglich sein, dann ein kritischer Abschnitt sollte den Job gut tun. Wenn Sie etwas zu schützen, die von den beiden Prozessen gemeinsam genutzt werden würden, wenn der Benutzer auf einmal zwei Instanzen des Programms laufen waren, dann müssen Sie wahrscheinlich einen Mutex.

Edit: Was mit einem kritischen Abschnitt verwenden, um zu schützen, was ril selbst tut, nein, das nicht der Fall ist (oder zumindest auf jeden Fall nicht ) benötigt werden. Mit einem Mutex, Sie zählen auf alle Prozesse zusammenarbeiten, um einen Mutex mit dem gleichen Namen zu steuern den Zugriff auf die gemeinsam genutzte Ressource zu öffnen (s). Sie können nicht darauf zählen, also wenn es die Schnittstelle benötigt wird, vollständig gebrochen ist.

Update: es sei denn, sie sind etwas wirklich ungewöhnlich in RIL tun, wird der Rückruf innerhalb Ihres Prozesses geschehen, so dass eine kritische ausreichend sein sollte. Wenn es Ihre Daten ändern, das heißt Ihre Daten abgebildet und sichtbar auf diesen Code - die die Daten in den Daten in dem kritischen Abschnitt bedeutet auch abgebildet und sichtbar wird, und es wird funktionieren. Die Zeit ein kritischer Abschnitt nicht funktioniert ist, wenn man es zu tun mit separaten Prozessen, so dass die Daten in einem nicht abgebildet / sichtbar in die andere.

Answer 4

Nun, ein anderer Unterschied zwischen einem Mutex und einem kritischen Abschnitt (Windows-Implementierungen, natürlich) ist, dass ein kritischer Abschnitt einspringenden ist - also dem gleichen Thread kann den kritischen Abschnitt zweimal erwerben, ohne sie lösen zu müssen.