lock java multithreading semaphore

java - Semaphore binario vs un ReentrantLock



java lock (2)

He estado tratando de comprender los bloqueos de reentrada y los semáforos (el anidamiento de los bloqueos de reentrada frente al mecanismo de liberación / desbloqueo).

Parece que tener un Semáforo requiere que escribas una aplicación más exhaustivamente probada porque el método release () no comprueba si el subproceso que libera el permiso realmente lo contiene. Cuando probé mi código de prueba, descubrí que esto podría aumentar posteriormente el número de permisos más allá del límite inicial. Por otro lado, si un subproceso no mantiene un bloqueo de reentrada cuando invoca el método de desbloqueo, obtenemos una excepción IllegalMonitorException.

Entonces, ¿sería correcto decir que no hay ninguna razón real para tener un semáforo binario, ya que todo lo que un semáforo binario puede hacer también puede hacerse mediante un ReentrantLock? Si usamos semáforos binarios tendríamos que verificar la pila de llamadas del método completo para ver si se adquirió un permiso anteriormente (también se liberó si existe la posibilidad de una adquisición posterior, lo que podría bloquear si una liberación no lo realiza y pronto ). Además, como los bloqueos reentrantes también proporcionan un bloqueo por objeto, ¿no es siempre una mejor idea preferir un bloqueo reentrante a un semáforo binario?

He comprobado una publicación aquí que habla de la diferencia entre un semáforo binario y un mutex, pero ¿hay algo como un mutex en Java?

Gracias, Chan.

PD: había publicado esta pregunta en otro foro ( http://www.coderanch.com/t/615796/threads/java/reason-prefer-binary-Semaphore-Reentrant ) y todavía no he recibido una respuesta. Pensé que lo publicaría aquí también para ver qué puedo obtener.


no hay ninguna razón real para tener un semáforo binario, ya que todo lo que puede hacer un semáforo binario también puede hacerse mediante un ReentrantLock

Si todo lo que necesita es una exclusión mutua reentrante, entonces sí, no hay razón para usar un semáforo binario sobre un ReentrantLock. Si, por alguna razón, necesita una semántica sin liberación de propiedad, obviamente el semáforo es su única opción.

Además, como los bloqueos reentrantes también proporcionan un bloqueo por objeto, ¿no es siempre una mejor idea preferir un bloqueo reentrante a un semáforo binario?

Depende de la necesidad. Como se explicó anteriormente, si necesita un mutex simple, no elija un semáforo. Si más de un hilo (pero un número limitado) puede ingresar a una sección crítica, puede hacerlo a través de un confinamiento de hilos o un semáforo.

He comprobado una publicación aquí que habla de la diferencia entre un semáforo binario y un mutex, pero ¿hay algo como un mutex en Java?

ReentrantLock y synchronized son ejemplos de ReentrantLock en Java.


No explicaré los bloqueos de reingreso ya que John ya ha dado una buena explicación arriba y es un ejemplo de exclusión mutua en java junto con la palabra clave sincronizada.

Sin embargo, si por alguna razón, le gustaría tener un mejor control sobre el mecanismo de bloqueo, Semaphore puede ser útil. Esto significa que su código tendrá que permanecer a cargo de quién llamó adquirir () y quién llamó liberar (), ya que Semaphore por naturaleza es ciego a él, todo lo que importa es que el permiso esté disponible.

Otro enfoque de su propia implementación de exclusión mutua utilizando Java es LockSupport. Funciona un poco como Semaphore, pero tiene un tiempo de espera en el permiso, usa la función park () y solo admite un permiso a la vez, a diferencia de los Semaphores que admiten varios de ellos.