¿Debo usar mutex o sección crítica para Windows Mobile RIL

Question

Estoy utilizando interfaz de capa de radio (RIL) API nativas en de aplicaciones de Windows Mobile . En este API, los valores de retorno / resultados de la mayoría de las funciones se no volvieron inmediatamente, pero se pasan a través de una función de devolución de llamada que se pasa a la API RIL.

Algunos ejemplos de uso se encuentran en XDA develompent Herramientas y Google Engranajes geolocalización API .

Mi pregunta es, en estos dos ejemplos, un mutex se utiliza para proteger los datos en lugar de otros objetos de sincronización.

Ahora, será crítico Sección hacer bien aquí en los casos de uso descritos por ambos ejemplos? ¿Qué proceso o subproceso en realidad será llamar a las funciones de devolución de llamada?

Editar
Mis datos se accede por mis códigos sólo desde dentro de mi proceso, sino que se enroscan / proceso está llamando a las funciones de devolución de llamada de API RIL? Es decir, pasé una devolución de llamada de función a la API de RIL, sino que son las devoluciones de llamada llamó desde otro proceso? en ese caso, se le dará otra explicación de por qué las muestras están usando mutex. Si la API RIL en realidad crea un hilo dentro de mi proceso y llama mis funciones de devolución de llamada, entonces creo sección crítica estaría bien (y es más rápido que un mutex).

Actualización:
Tengo datos que es (1) visitada por mis códigos de dentro de mi propio proceso y también es (2) modificado a partir de una devolución de llamada de función. La devolución de llamada se realiza mediante la API de RIL.

Mi Pregunta: ¿Qué tema / proceso está llamando a las funciones de devolución de llamada de API RIL?

La historia hasta ahora:
Me:. Hola Sr. RIL, por favor poner algunos datos en mi oficina (a.k.a las variables)
RIL: Aceptar Sir. Voy a poner los datos más adelante y voy a señalar que cuando se hace (utilicé un evento aquí).

Se requiere una tarjeta de acceso para entrar en mi oficina. Si el señor RIL es de la misma empresa que yo, señor RIL puede utilizar su propia tarjeta de acceso para entrar en mi oficina (en mi caso, significa una sección crítica). Si él es de otras compañías, necesitaré para configurar una tarjeta de tarjeta de acceso / visitante para él (en mi caso, necesito un mutex aquí).

Si el señor RIL utiliza su propia tarjeta de acceso, significa que no necesito para configurar una tarjeta de la tarjeta / visitante el acceso a él y que significa menos problemas para mí. (Es decir, sección crítica es más rápido que un objeto mutex)

El problema es, acabo de conocer a este señor RIL hace unos días y no sé mucho sobre él. No sé si es de la misma empresa que yo. Una opción como mencionó por nobugz es la creación de una tarjeta de acceso para el señor RIL sin tener en cuenta si el Sr. RIL es de la misma empresa que yo. De esta manera, el Sr. RIL se garantiza que sea capaz de entrar en mi oficina. (Mis datos / variables están garantizados para estar seguro)

En este momento yo uso en mi código de exclusión mutua (configurar una tarjeta de acceso posiblemente redundante para el Sr. RIL).

Aha! Sólo tiene una idea al escribir esto. Creo que simplemente voy a pedir al señor RIL de la que él es empresa. De esa manera, no tiene que configurar la tarjeta de acceso para él en el futuro si resulta ser en la misma empresa que yo. (Es decir, poner GetCurrentProcessId() y GetCurrentThreadId() en la función de devolución de llamada)

Answer 1

El Mobile RIL de Windows reside normalmente en Device.exe (por WM6.x). Sin embargo, cuando el proceso invoca el RIL, la llamada pasa a través del proxy RIL.

El proxy RIL está vinculado con, y reside en su proceso, y se ocupa de todas las cuestiones relacionadas con los límites del proceso para usted (como un aparte, esto es, al menos, parte de la razón por la cual todas las estructuras de datos EIR necesitan ser envasados en un solo bloque de memoria de tamaño conocido). Internamente, el proxy RIL crea un hilo en el que se ejecuta su devolución de llamada.

Esto significa que su código se puede utilizar un objeto CRITICAL_SECTION para proporcionar la sincronización / protección necesaria.

Answer 2

El punto de usar el mutex es que usted no sabe lo que el hilo podría hacer la devolución de llamada. Sí, una sección crítica funcionaría también. Cuidado, hacerlo mal hace al azar y muy difícil de diagnosticar fallos.

Answer 3

Una sección crítica es un mutex. Una sección crítica es diferente de un mutex normal (al menos principalmente) de una manera:. Que es específico de un proceso, donde un mutex se puede utilizar en procesos

Por lo tanto, en este caso, la pregunta básica es exactamente lo que está protegiendo - si se trata de los datos dentro de su programa, que no se podrá acceder a otro proceso, a continuación, una sección crítica debe hacer el trabajo muy bien. Si va a proteger algo que sería compartida por los dos procesos si el usuario ejecute dos instancias de su programa a la vez, entonces es probable que tenga un mutex.

Editar: En lo que a tener que utilizar una sección crítica para proteger lo hace en sí RIL, no, eso no es (o al menos sin duda no debe ) se necesitarían. Con un mutex, usted está contando en todos los procesos de cooperar con la apertura de un mutex con el mismo nombre para controlar el acceso al recurso (s) compartido. No se puede contar con eso, así que si se necesita la interfaz es completamente roto.

Actualización: a menos que están haciendo algo realmente inusual en RIL, la devolución de llamada va a pasar dentro de su proceso, por lo que un crítico debe ser adecuada. Si se trata de la modificación de sus datos, lo que significa que sus datos se mapea y visible a ese código - lo que significa que los datos en los datos de la sección crítica también se asignarán y visible, y que va a trabajar. El tiempo de una sección crítica no funciona es cuando se está tratando con procesos separados, por lo que los datos en uno, no es asignada / visible para el otro.

Answer 4

Bueno, otra diferencia entre un mutex y una sección crítica (implementaciones de Windows, por supuesto) es que una sección crítica es reentrante -. Es decir, el mismo hilo puede adquirir la sección crítica dos veces sin tener que liberarlo