.net - sistemas - sincronizacion de procesos
Se busca: sincronización de procesos cruzados que no sufre de AbandonedMutexException (3)
Tengo varios hilos que adquieren Mutexes y luego terminan.
Los mutexes se almacenan en un repositorio principal y se liberan correctamente cuando existe el programa. Sin embargo, cuando existe el hilo que asignó un Mutex, el mutex se libera automáticamente y posteriormente adquiere AbandonedMutexException (también según la documentación ).
¿Cómo puedo evitar esta excepción y seguir utilizando un Mutex incluso después de que termine el hilo de asignación? ¿Existe otra construcción de sincronización más apropiada en .Net que no tenga esta limitación?
Nota : Estoy buscando un mecanismo de sincronización entre procesos con semántica similar a Mutex.
Parece que EventWaitHandle hace lo que yo quiero. Tiene un constructor que toma un nombre, por lo que es perfecto para la sincronización de procesos cruzados, y no tiene este problema.
Respuesta a la pregunta
AFAIK no existe tal clase Mutex. La excepción AbandonedMutex es bastante molesta, pero representa una situación real que puede ocurrir para la cual no hay una solución automática.
Cuando tiene un proceso cruzado, o incluso una comunicación cruzada, debe tratar con el hecho de que cualquiera de las entidades participantes puede ser inesperada y cancelada repentinamente por varias razones. Existen mutex para proteger recursos, si se abandona un hilo mientras contiene un mutex, no hay forma de que el sistema operativo garantice que dejó datos de manera consistente. Esto es muy importante porque significa que el abandono del hilo podría haber invalidado ciertas invariantes de las que dependen otros hilos.
AbandonedMutexException es una forma de decir de manera proactiva "sucedieron cosas malas y ahora se encuentra en un estado indeterminado". Realmente no hay otras recetas para el sistema operativo aquí.
Respuesta a tu respuesta
EventWaitHandle es diferente de Mutex y sirve para diferentes propósitos.
Mutex se usa para proteger un recurso en particular como una declaración de bloqueo. Cuando un hilo en particular adquiere un mutex, se dice que posee el Mutex. Solo puede haber un propietario a la vez. Entonces, si todos los hilos implicados aceptan solo tocar un recurso cuando tienen la propiedad del Mutex, puede acceder de forma segura a un recurso a través de thread.s
EventWaitHandle se puede visualizar, hasta cierto punto, como un evento seguro para subprocesos. Tiene el concepto de señalizado y desmarcado y cualquier cantidad de subprocesos puede esperar a que llegue a un estado señalizado. Cuando se señala, uno de los hilos de espera se activará y comenzará a procesarse.
Puede usar un EventWaitHandle para implementar una forma de seguridad de subprocesos. En lugar de bloquear la propiedad como la clave para acceder al recurso, la señalización del evento es la clave para acceder al recurso. Sin embargo, el diablo está una vez más en los detalles.
- ¿Quién está a cargo de señalar el evento? Con un mutex, cada hilo esencialmente grita "me me me" y el sistema operativo elige un hilo para ganar. Con un EventWaitHandle, usted será responsable de decidir cuándo irá el siguiente hilo.
- ¿Qué sucede cuando alguien mata un proceso a través de taskmgr? ¿Qué sucede si el proceso cancelado tiene un hilo que responde actualmente a un evento en el EventWaitHandle?
2 pero, ¿qué sucede cuando se quita el elemento que llega a señalar el identificador de espera siguiente? Debe tener esto en cuenta para evitar un punto muerto.
No hay nada que le impida usar el Mutex después de recibir una AbandonedMutexException . Del doc :
El siguiente hilo para solicitar la propiedad del mutex puede manejar esta excepción y continuar, siempre que se pueda verificar la integridad de las estructuras de datos.
Por supuesto, esto supone que usted sabe lo que usted (y sus subprocesos) están haciendo mientras bloquean, y eso básicamente significa que el hilo de adquisición podría liberar el mutex antes de salir.
Así que, al final, su propia solución de usar EvenWaitHandle es mejor que el mutex.