title: Binary Semaphore vs a ReentrantLock
body: <p>I've been trying to understand Reentrant locks and Semaphores ( the nesting of Reentrant locks vs release/unlock mechanism ).</p>
  
  <p>It seems that having a Semaphore requires you to write a more thoroughly tested application because the release() method does not check if the thread releasing the permit is actually holding it. When I tested my test code, I found out that this may subsequently increase the number of permits beyond the initial limit. On the other hand, if a thread is not holding a reentrant lock when it invokes the unlock method, we get an IllegalMonitorException.</p>
  
  <p>So would it be right to say that there is no real reason ever to have a binary semaphore as everything that a binary semaphore can do can also be done by a ReentrantLock. If we use binary semaphores we would have to check the entire method call stack to see if a permit was acquired before ( also was it released too if there is a possibility of a subsequent acquire - which might block if a release does not proceed it and so on ). Also since reentrant locks also provide one lock per object, isn't it always a better idea to prefer a reentrant lock to a binary semaphore?</p>
  
  <p>I have checked a post here that talks about difference between a binary semaphore and a mutex but is there a thing like a mutex in Java?</p>
  
  <p>Thanks,
  Chan.</p>
  
  <p>P.S - I had posted this question in another forum ( <a href="http://www.coderanch.com/t/615796/threads/java/reason-prefer-binary-Semaphore-Reentrant">http://www.coderanch.com/t/615796/threads/java/reason-prefer-binary-Semaphore-Reentrant</a> ) and I haven't received a response yet. I thought I'd post it here as well to see what I can get.</p>