Acceso a datos compartidos desde un controlador de señal

Question

Deseo saber si es una buena idea acceder a los datos compartidos desde un manejador de señal. Me refiero a considerar el escenario de sistema de procesos múltiples y sistema multiproceso con un solo proceso. En el sistema de procesos múltiples, digamos que los procesos manejan una señal particular y actualizan cierta variable o memoria compartida por los procesos. ¿Puedo hacer eso desde el manejador de señales en sí?

Sin embargo, en el caso de los hilos que usan pthreads, no creo que sea factible. http://maxim.int.ru/bookshelf/PthreadsProgram/htm/r_40.html. Como se indica en este artículo, han mencionado que no es segura la señal asíncrona y han sugerido usar sigwait para eso. No soy el motivo por el cual no es segura la señal asíncrona. Quiero decir, digamos que manejo una señal por un hilo y está en el enrutamiento del manejador de señal. Adquiero un candado en la memoria compartida para actualizarlo. Mientras tanto, llega otra señal del mismo tipo y otro subproceso responsable de su manejo ejecuta nuevamente el manejador de señal. Aquí, el manejador de señal es el mismo para el proceso, pero se llama tiempo múltiple. La segunda vez, no puede ver el bloqueo y las actualizaciones/anula los datos. ¿Es este el problema con los manejadores de señal multiproceso que usan datos compartidos?

Estoy un poco confundido, en los sistemas de procesos múltiples, tengo una copia del manejador de señal para cada proceso. Pero en el sistema multiproceso, hay una sola copia del manejador de señal utilizada por los hilos múltiples, ¿no es así? Entonces, cuando llegan varias señales del mismo tipo y tenemos dos hilos que son responsables de su manejo, intenten manejarlo, ¿entonces ambos intentarán ejecutar el mismo código de controlador? ¿Cómo encaja todo?

Answer 1

leí el artículo que se hace referencia y se encontró alguna información interesante en los "Temas en manejadores de señales" sección. En esa sección, verás que tienen una lista de llamadas a la función de Posix que se pueden realizar desde dentro de los controladores de señal. Luego, poco después de esa lista, mencionan lo siguiente:

Pero, ¿dónde están las llamadas Pthreads? ¡No están en ninguna de estas listas ! De hecho, el estándar Pthreads especifica que el comportamiento de todas las funciones Pthreads no está definido cuando se llama a la función desde un controlador de señal . Si su manejador necesita manipular datos que están compartidos con otros hilos≈buffers, indicadores o variables de estado≈está desactivado de suerte. Las llamadas de mutexto y condición de sincronización Pthreads están fuera de los límites.

Aviso la última frase: "Pthreads mutex y condición llamadas de sincronización variable están fuera de los límites"

Las funciones mencionadas anteriormente que pueden ser llamados a partir de un controlador de señal se describen como sigue:

Estos funciones tienen una propiedad especial conocida como reentrada que permite a un proceso tener varias llamadas a estas funciones en progreso al mismo tiempo.

Las funciones de sincronización pthread no tiene la propiedad especial conocido como reentrada, así que imaginar que si estas funciones (pthread_mutex_lock() por ejemplo) son interrumpidos por una señal que llega, entonces el comportamiento no es "seguro".

Imagine que su aplicación llama al pthread_mutex_lock(&theMutex) y exactamente en ese momento (es decir, mientras está en la función pthread_mutex_lock()) llega una señal.Si el manejador de señal también llama al pthread_mutex_lock(&theMutex), la llamada pthread anterior puede no haber finalizado, por lo que no se puede garantizar qué llamada a pthread_mutex_lock() obtendrá el bloqueo. Entonces, el comportamiento resultante será indefinido/indeterminado.

Me imagino que la llamada a sigwait() desde un hilo en particular garantizaría que no se interrumpan las llamadas a las funciones non-reentrancy, lo que permite que las llamadas a las funciones de sincronización pthread sean "seguras".