Semáforo binario vs ReentrantLock
He estado tratando de entender los bloqueos de reentrada y los semáforos ( el anidamiento de los bloqueos de reentrada vs el mecanismo de liberación/desbloqueo ).
Parece que tener un semáforo requiere que escribas una aplicación probada más a fondo 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 puede aumentar posteriormente el número de permisos más allá del límite inicial. Por otro lado, si un hilo es al no mantener un bloqueo de reentrada cuando invoca el método de desbloqueo, obtenemos una IllegalMonitorException.
Así que 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 se puede hacer por un ReentrantLock. Si usamos semáforos binarios, tendríamos que verificar toda la pila de llamadas al método para ver si un permiso fue adquirido antes (también se liberó también si hay una posibilidad de una adquisición posterior , lo que podría bloquear si una liberación no procede y así sucesivamente). Además, dado que los bloqueos de reentrada también proporcionan un bloqueo por objeto, ¿no es siempre una mejor idea preferir un bloqueo de reentrada a un semáforo binario?
He revisado un post aquí que habla de la diferencia entre un semáforo binario y un mutex, pero ¿hay algo como un mutex en Java?
Gracias, Chan.
P. S - Yo había publicado esta pregunta en otro foro ( http://www.coderanch.com/t/615796/threads/java/reason-prefer-binary-Semaphore-Reentrant ) y aún no he recibido respuesta. Pensé en publicarlo aquí también para ver qué puedo conseguir.
2 answers
No hay ninguna razón real para tener un semáforo binario como todo lo que un semáforo binario puede hacer también se puede hacer por un ReentrantLock
Si todo lo que necesita es una exclusión mutua de reentrada, entonces sí, no hay razón para usar un semáforo binario sobre un reentrante. Si por alguna razón necesitas semántica de no-propiedad-liberación entonces obviamente el semáforo es tu única opción.
También dado que los bloqueos de reentrada también proporcionan un bloqueo por objeto, ¿no es Siempre una mejor idea para preferir un bloqueo de reentrada a un semáforo binario?
Depende de la necesidad. Como se explicó anteriormente, si necesita un simple mutex, entonces no elija un semáforo. Si más de un hilo (pero un número limitado) puede entrar en una sección crítica, puede hacerlo a través del confinamiento del hilo o de un semáforo.
He revisado un post aquí que habla de la diferencia entre un semáforo binario y un mutex pero hay una cosa como un mutex en ¿Java?
ReentrantLock y synchronized son ejemplos de mutexes en Java.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-07-16 17:56:19
No explicaré los bloqueos de reentrada ya que John ya ha dado una buena explicación arriba y es un ejemplo de mutex en java junto con la palabra clave sincronizada.
Sin embargo, si por alguna razón, desea tener un mejor control sobre el mecanismo de bloqueo, el semáforo puede ser útil. Esto significa que tu código tendrá que permanecer a cargo de quién llamó a acquire() y quién llamó a release() ya que Semaphore por naturaleza es ciego a ello, todo lo que le importa es que el permiso se convierta en disponible.
Otro enfoque de su propia implementación de mutex usando java es LockSupport. Funciona un poco como Semáforo pero tiene un tiempo de espera en el permiso, usando la función park () y solo soporta un permiso a la vez a diferencia de los semáforos que soportan varios de ellos.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-08-23 19:46:18