Hay un escenario, tengo dos hilos que usan el mismo mutex. Un hilo bloqueó el mutex y se estrelló. ¿Cuál sería el estado mutex? ¿Todavía está bloqueado y el segundo hilo nunca posee ese mutex? Significa una situación de punto muerto?Hilo bloqueado con Mutex bloqueado
Editar - También se debe aclarar un caso de pthread en sistemas Linux
Dado que no ha especificado qué sistema operativo, te voy a decir lo que sucede en Win32.
En Win32, el segundo subproceso obtendría WAIT_ABANDONED cuando va a esperar en el mutex propiedad de un subproceso que ha finalizado. Tenga en cuenta que recibir WAIT_ABANDONED significa que el segundo hilo ha recibido el mutex, por lo que no habrá un punto muerto. El segundo subproceso debería detectar el resultado WAIT_ABANDONED y verificar que el recurso protegido por el mutex está en un estado válido. Si puede detectar corrupción y no detecta ninguna, es seguro proceder. Si no, es una buena idea presentar un error de algún tipo.
Con algunas implementaciones de un mutex no hay forma de detectar que el hilo que lo posee ha terminado, y termina con un interbloqueo.
Con algunas implementaciones de un mutex hay una manera de detectar cuál es el hilo propietario, darse cuenta de que el hilo propietario ha finalizado, y luego tomar posesión del mutex.
en algunas implementaciones puede definir el tiempo de espera o crea su propio método envoltorio ... de todos modos, la suspensión de subprocesos no tiene efecto en mutex \ semáforo en la implementación clásica, por lo que es una buena idea verificar el tiempo de espera y aumentar la excepción o reanudar la ejecución. – Oleksandr
Lo siento por la mitad de la pregunta. Esto es en el sistema operativo Windows y también le gusta conocer el otro comportamiento del sistema operativo. Gabe: Si siempre obtiene el WAIT_ABANDONED, entonces puede ser manejado fácilmente. De nuevo, ¿hay un punto muerto? Cómo detectamos que el hilo del propietario se ha bloqueado. Joonas Pulakka: Solo asume que el hilo se colgó con NULL. Significa ninguna excepción o ningún reconocimiento. – CrazyC
Eso depende ciertamente de (al menos) dos cosas:
Por ejemplo, en synchronized bloques de Java están garantizados para ser liberado cuando el "hilo se realiza con el objeto" - sea lo que sea (ver link). De acuerdo con el artículo this:
Al detener un hilo, se desbloquea todos los monitores que ha bloqueado.
Ok, stop() ing los comunicados de los monitores de hilo, pero lo que si un hilo simplemente desaparece de alguna manera, es entonces "realiza con el objeto"? No veo esto documentado en ningún lado. Pero es obvio que alguien debe liberar mutexes bloqueados, o de lo contrario se estancarán; quizás algunos mutexes o entornos incluyen mecanismos que liberan mutexes automáticamente si el hilo, que los bloqueó, se vuelve inexistente.
Otro ejemplo: java.util.concurrent.Lock se recomienda utilizar una declaración finally para liberar el bloqueo de manera que pase lo que pase con el hilo en ejecución, se libere el bloqueo. Pero, si el hilo desaparece antes de que se ejecute la instrucción finally, entonces el bloqueo nunca se libera y de hecho ocurre un interbloqueo. Por supuesto, los hilos no deberían "desaparecer" simplemente así.
¡Una buena pregunta!
pregunta es buena, pero cada implementación tiene su propio mecanismo y solución para resolver el problema descrito, pero solo pudimos adivinar qué significa el autor :) – Oleksandr
Gracias por su respuesta. http://msdn.microsoft.com/en-us/library/ms687032%28VS.85%29.aspx MSDN también dice que libera el mutex y los subprocesos de espera obtienen el estado WAIT_ABANDONED.
Proporcione información adicional. – InsertNickHere