usar studio sincronizar remota nube externa expenses datos crunch create conexion con bases app synchronization hardware process pthreads named-pipes

synchronization - studio - ¿Cómo sincronizo dos procesos?



sqlite en la nube (6)

Como solo necesitas contar un semáforo de uno, basta un mutex.

Tengo una única interfaz HW que quiero usar desde dos aplicaciones (procesos) en la misma estación de trabajo. El HW requiere una sola llamada de inicialización, luego, cualquiera de las aplicaciones usa la misma función (en la misma biblioteca) para hacer muchas transacciones con el HW.

Entonces cada aplicación debería actuar así:

main() // I don''t know if another app already init''ed the HW ret = hw_init_lock(non-blocking) if ret = OK // no one else has done this, I have to init_hw() else //someone else has already init''ed the HW, I gotta make sure it stays that way //as long as I''m alive increment_hw_init_ref_counter() hw_trans_lock(blocking) hw_trans() hw_trans_unlock() .... //exit app, uninit hw if we are last out ret = decrement_hw_init_ref_counter() if ret == 0 uninit_hw() exit(0)

¿Cuál es el mecanismo que puedo usar en las llamadas de conteo de bloqueo y referencia que se comparten entre dos aplicaciones? Estoy pensando en tubos con nombre, es decir, mkfifo ().

Semáforos y mutexes / variables de condición son buenas primitivas de muy alto rendimiento que son apropiadas para el uso entre subprocesos o entre procesos.

Todos estos se basan en la idea (y generalmente, en la realidad) de probar y establecer u otras operaciones atómicas realizadas en la memoria compartida.

Si espera distribuir sus procesos a través de la red, los semáforos y mutexes pueden no ser adecuados para usted, solo funcionan en una sola máquina. Las tuberías y tomas son, en general, extensibles a la red.

Un breve resumen de mutexes, variables de condición y semáforos:

Mutexes

Un mutex es una primitiva que puede estar bloqueada o desbloqueada. El proceso / hilo que lo bloqueó debe ser el que lo desbloquee. Este aspecto de propiedad permite que el sistema operativo aplique algunas optimizaciones interesantes, como la herencia de prioridad y el protocolo de techo de prioridad (para evitar la inversión de prioridad). sin embargo , el mutex no tiene un recuento asociado. No puede bloquear un mutex ya bloqueado, en general, y retener la memoria que estaba "bloqueado dos veces" (hay algunas extensiones que lo permiten, creo, pero no están disponibles en todas partes)

Variables de condición

Un mutex es ideal para ... bueno, MUTual EXclusion. Pero, ¿qué sucede si necesita bloquear una condición asociada con el objeto al que tiene exclusión mutua? Para esto, usa una variable de condición, o CV. Un CV está asociado con un mutex. Por ejemplo, supongamos que tengo una cola de datos de entrada a la que mis procesos quieren acceder. Uno agarra el mutex para que pueda mirar la cola sin temor a interferencias. Sin embargo, encuentra la cola vacía y quiere esperar a que algo entre en la cola. Por lo tanto, espera en la variable de condición "cola no vacía". La parte interesante aquí es que, debido a que el CV está asociado con el mutex, el mutex se vuelve a adquirir automáticamente una vez que se señala la variable de condición. Por lo tanto, una vez que el proceso se despierta después de esperar en el CV, sabe que tiene acceso exclusivo nuevamente a la cola. Lo que no sabe es si la cola realmente tiene algo -tal vez dos procesos esperaron en el CV- entró una cosa, y la primera prioridad entró y quitó la "cosa" antes de que la segunda cosa se despertara. Por lo tanto, cada vez que use un CV, debe RECHAZAR la condición, así:

mutex_enter(m); while (! condition) { cond_wait(m, c); // drop mutex lock; wait on cv; reacquire mutex } //processing related to condition mutex_exit(m);

Semáforos

OK, eso es mutexes y variables de condición. Los semáforos son más simples. Se pueden incrementar y disminuir mediante cualquier proceso. Tienen memoria, cuentan, por lo que puedes usarlas para determinar cuántas de una condición han ocurrido. No ocurre lo mismo con las variables de condición. Además, como los semáforos se pueden disminuir en un proceso y aumentar en otro, no tienen el aspecto de propiedad, por lo que no es posible heredar la prioridad ni evitar la inversión prioritaria.

Ahora, finalmente, todos estos mecanismos requieren memoria compartida para una implementación eficiente. Esto puede estar bien para usted, pero tenga en cuenta que si cree que su aplicación se puede distribuir finalmente, entonces mutexes, variables de condición y semáforos pueden no ser para usted. Las tuberías y tomas de corriente, aunque tienen una sobrecarga mucho mayor, tienen la posibilidad de extenderse por la red de manera bastante sencilla.

yo asumo eso

... que se comparte entre dos aplicaciones?

significa que desea que estas dos cosas se ejecuten como procesos separados? Si eso no es cierto, y se están ejecutando como un proceso único (con múltiples hilos), entonces las sugerencias de semáforos y mutex son la mejor opción y deberían ser bastante sencillas.

Tenga en cuenta que la respuesta dependerá exactamente de cómo esté accediendo a este hardware. Por ejemplo, si está expuesto a través de un archivo, se puede usar el bloqueo de archivos normal.

Sin embargo, si intenta sincronizar el acceso al hardware en dos procesos, eso es algo diferente. Supongo que lo primero que hay que decir es que será más fácil sincronizar, si se puede, tener un único proceso a cargo del acceso al hardware. En este modelo, es posible que tenga un proceso que actúe como servidor para el hardware: acepte solicitudes de otros procesos y realice las lecturas y escrituras en su nombre. Casi cualquier forma de comunicación entre procesos será adecuada, pero para simplificar algo como la cola de mensajes ( enlace ) puede ser apropiado con una estructura de datos apropiada (por ejemplo, una bandera para indicar si se trata de una operación de lectura o escritura, desviada de la dirección base de su hardware, número de bytes, búfer (en caso de escribir)

Si no es apropiado poner todo el acceso directo al hardware en un solo proceso, entonces deberá usar un esquema de sincronización apropiado. Investigaría el uso de bloqueos de archivos (e implementaría un esquema mutex rudimentario), o usar semáforos con nombre (como ha sugerido albertb)

El semáforo POSIX es el camino a seguir. Como desea compartir el mismo semáforo entre los procesos, debe usar un semáforo con nombre:

Un semáforo con nombre se identifica con el nombre de la forma / nombre. Dos procesos pueden operar en el mismo semáforo con nombre pasando el mismo nombre a sem_open (3).