Se busca: sincronización entre procesos que no sufra de AbandonedMutexException

Question

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 el subproceso que asignó un Mutex existe, el mutex se libera automáticamente y, posteriormente, adquiere AbandonedMutexException (también de acuerdo con la documentación ).

¿Cómo puedo evitar esta excepción y seguir usando un Mutex incluso después de que finalice 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 una semántica similar a Mutex.

Answer 1

Parece que EventWaitHandle hace lo que quiero. Tiene un constructor que toma un nombre, por lo que es perfecto para la sincronización entre procesos y no tiene este problema.

Answer 2

Respuesta a la pregunta

AFAIK no existe tal clase Mutex. La AbandonedMutexException 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 entre hilos, debe lidiar con el hecho de que cualquiera de las entidades participantes puede ser inesperada y terminar repentinamente por cualquier número de razones. Los Mutex existen para proteger los recursos, si un hilo se abandona mientras contiene un Mutex, no hay forma de que el sistema operativo garantice que dejó los datos de manera consistente. Esto es muy importante porque significa que el abandono del hilo podría haber invalidado que ciertos hilos dependieran de ciertos invariantes.

La AbandonedMutexException es una forma de decir de manera proactiva "cosas malas que sucedieron y ahora estás en un estado indeterminado". Realmente no hay otros recursos para el sistema operativo aquí.

Respuesta a su respuesta

EventWaitHandle es diferente a Mutex y sirve para diferentes propósitos.

Mutex se utiliza para proteger un recurso particular de forma muy similar a una declaración de bloqueo. Cuando un subproceso particular adquiere un mutex, se dice que posee el Mutex. Solo puede haber un propietario a la vez. Entonces, si todos los hilos involucrados acuerdan tocar solo un recurso cuando tienen la propiedad de 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 sin señalizar y cualquier cantidad de subprocesos puede esperar a que llegue a un estado señalado. Cuando se señale, uno de los hilos en espera se despertará y comenzará a procesarse.

Puede usar un EventWaitHandle para implementar una forma de seguridad de subprocesos. En lugar de que la propiedad del bloqueo sea la clave para acceder al recurso, la señalización desde el evento es la clave para acceder al recurso. Sin embargo, el diablo está una vez más en los detalles.

1. ¿Quién está a cargo de señalar el evento? Con un mutex, cada hilo está esencialmente gritando "yo, yo, yo". y el sistema operativo elige un hilo para ganar. Con un EventWaitHandle, usted será responsable de decidir cuándo llegará el siguiente hilo.
2. ¿Qué sucede cuando alguien mata un proceso a través de taskmgr? ¿Qué sucede si el proceso finalizado tiene un hilo que actualmente responde a un evento en EventWaitHandle?

3. 2, pero ¿qué sucede cuando se quita el elemento que indica la siguiente espera? Debe tener esto en cuenta para evitar un punto muerto.

Answer 3

No hay nada que le impida usar Mutex después de recibir una AbandonedMutexException . Del doc :

  

El siguiente hilo para solicitar la propiedad del mutex puede manejar esto   excepción y proceder, siempre que la integridad de los datos   las estructuras se pueden verificar.

Por supuesto, esto supone que sabe lo que usted (y sus hilos) están haciendo mientras se bloquean, y eso básicamente significa que el hilo de adquisición también podría liberar el mutex antes de salir.

Entonces, al final, su propia solución de usar EvenWaitHandle es mejor que el mutex.