Dois-je utiliser Mutex ou à la section critique pour Windows Mobile RIL

Question

J'utilise Layer Interface Radio (RIL) API natives applications Windows mobile . Dans cette API, les valeurs de retour / résultats de la plupart des fonctions ne sont pas retournés immédiatement, mais sont passés à travers une fonction de rappel qui est transmis à l'API RIL.

Voici quelques exemples d'utilisation se trouvent à Outils XDA Develompent et Google Gears href="http://code.google.com/apis/gears/api_geolocation.html" rel="nofollow noreferrer"> API .

Ma question est, dans ces deux exemples, un mutex est utilisé pour protéger les données plutôt que d'autres objets de synchronisation.

, va section critique faire bien ici dans les cas d'utilisation décrites par les deux exemples? Quel fil ou processus fait appel aux fonctions de rappel?

Edit: Mes données est accessible par mes codes que de l'intérieur de mon processus, mais quel thread / processus appelle les fonctions de rappel dans API RIL? Je veux dire, je suis passé un rappel de fonction à l'API RIL, mais sont les callbacks appelé d'autres processus? dans ce cas, il donnera une autre explication pourquoi les échantillons utilisent Mutex. Si l'API RIL crée en fait un fil à l'intérieur de mon processus et appelle mes fonctions de rappel, alors je pense que la section critique serait bien (et il est plus rapide qu'un mutex).

Mise à jour: J'ai des données qui est (1) accessible par mes codes à partir de mon propre processus et est également (2) modifié à partir d'un rappel de la fonction. Le rappel se fait par l'API RIL.

Ma Question: Quel fil / processus appelle les fonctions de rappel dans API RIL?

L'histoire jusqu'à présent:
Me:. Salut M. RIL, s'il vous plaît mettre des données dans mon bureau (a.k.a variables)
RIL: OK Monsieur. Je vais mettre les données plus tard et je vous signaler quand il est fait (je un événement ici).

Une carte d'accès est nécessaire pour entrer dans mon bureau. Si M. RIL est de la même entreprise que moi, M. RIL peut utiliser sa propre carte d'accès pour entrer dans mon bureau (dans mon cas, cela signifie une section critique). S'il est d'autres entreprises, je dois mettre en place une carte carte / visiteur l'accès pour lui (dans mon cas, je besoin d'un mutex ici).

Si M. RIL utilise sa propre carte d'accès, cela signifie que je ne ai pas besoin de mettre en place une carte carte / visiteur d'accès pour lui et cela signifie moins de problèmes pour moi. (À savoir la section critique est plus rapide qu'un Mutex)

Le problème est, je viens de rencontrer ce M. RIL il y a quelques jours et je ne sais pas grand chose sur lui. Je ne sais pas s'il est de la même entreprise que moi. Une option que mentionné par nobugz est de mettre en place une carte d'accès pour M. RIL indépendamment du fait que M. RIL est de la même entreprise que moi. De cette façon, M. RIL est garanti d'être en mesure d'entrer dans mon bureau. (Mes données / variables sont garantis pour être sûr)

En ce moment j'utilise mutex dans mon code (mis en place une carte d'accès peut-être redondant pour M. RIL).

Aha! Juste eu une idée en écrivant cela. Je pense que je vais demander M. RIL à partir de laquelle il est entreprise. De cette façon, je ne pas mettre en place une carte d'accès pour lui à l'avenir s'il se révèle être dans la même entreprise que moi. (À savoir mettre GetCurrentProcessId() et GetCurrentThreadId() dans la fonction de rappel)

Answer 1

Le Windows Mobile RIL réside normalement dans Device.exe (pour WM6.x). Cependant, lorsque votre processus appelle l'RIL, votre appel passe par le proxy RIL.

Le proxy RIL est lié, et réside dans votre processus, et gère toutes les questions liées aux limites du processus pour vous (en aparté, c'est au moins une partie de la raison pour laquelle toutes les structures de données RIL doivent être emballés dans un seul bloc de mémoire de taille connue). En interne, le Proxy RIL crée un fil sur lequel votre rappel est exécutée.

Cela signifie que votre code peut utiliser un objet CRITICAL_SECTION pour fournir la synchronisation nécessaire / protection.

Answer 2

Le point d'utiliser le mutex est que vous ne savez pas quel fil pourrait faire le rappel. Oui, une section critique fonctionnerait aussi. Attention, se tromper fait au hasard et très difficile à diagnostiquer l'échec.

Answer 3

Une section critique est un mutex. Une section critique est différent d'un mutex normal (au moins essentiellement), d'une façon:. Il est spécifique à un procédé, dans lequel un mutex peut être utilisé dans les procédés

Alors, dans ce cas, la question fondamentale est exactement ce que vous protégez - si ce sont les données contenues dans votre programme, qui ne seront pas accessibles à un autre processus, une section critique doit faire le travail bien. Si vous protégez quelque chose qui serait partagée par les deux processus si l'utilisateur d'exécuter deux instances de votre programme à la fois, alors vous avez probablement besoin d'un mutex.

Edit: En ce qui avoir à utiliser une section critique pour protéger ce que RIL se fait, non, ce n'est pas (ou du moins certainement ne devrait pas ) seront nécessaires. Avec un mutex, vous comptez sur tous les processus coopérez en ouvrant un mutex avec le même nom pour contrôler l'accès à la ressource partagée (s). Vous ne pouvez pas compter sur cela, donc si elle est nécessaire, l'interface est complètement brisée.

Mise à jour: à moins qu'ils font quelque chose de vraiment inhabituel dans RIL, le rappel se produira au sein de votre processus, donc une critique devrait être suffisant. Si elle est la modification de vos données, qui signifie que vos données sont mappées et visible à ce code - ce qui signifie que les données contenues dans les données de la section critique seront également cartographiées et visible, et que ça va marcher. Le temps d'une section critique ne fonctionne pas est quand vous avez affaire à des processus distincts, de sorte que les données ne sont pas mises en correspondance un / visible à l'autre.

Answer 4

Eh bien, une autre différence entre un mutex et une section critique (implémentations Windows, bien sûr) est qu'une section critique est rentrante -.-À-dire le même fil peut acquérir la section critique deux fois sans avoir à libérer