Home arrow static arrow Java Programming [Archive] - reliable semaphore implementation question
Warning: Creating default object from empty value in /www/htdocs/w008deb8/wiki/components/com_staticxt/staticxt.php on line 51
Java Programming [Archive] - reliable semaphore implementation question
This topic has 3 replies on 1 page.

Posts:835
Registered: 2/12/01
reliable semaphore implementation question  
Jun 27, 2004 8:14 AM



 
Author of "Concurrent programming in Java" book brings the following observation on reliable implementation of semaphore:

To maintain responsiveness, we should check to make sure that the current thread has not been interrupted before acquiring any locks. This minimizes windows of vulnerability for client threads getting stuck waiting for locks when they should be cancelling themselves (see ? 3.1.2). It also provides a more uniform guarantee that InterruptedException will be thrown if the thread enters in an interrupted state, rather than having the exception thrown only if the thread happens to block on the internal wait.


And brings the following implementation example:
class Semaphore implements Sync {  protected long permits; // current number of available permits  public Semaphore(long initialPermits) {  permits = initialPermits; }  public synchronized void release() {  ++permits;  notify(); } public void acquire() throws InterruptedException {  if (Thread.interrupted()) throw new InterruptedException();   // <-- what if we interrupt it here?  synchronized(this) {   try {     while (permits <= 0) wait();     --permits;   }   catch (InterruptedException ie) {    notify();    throw ie;   }  } } 


It checks for interrupted outside sychronized block. What if we interrupt the thread when it has checked the flag waiting? Effectively, it can wait forever. It is not absolutely reliable implementaion, isn't it?
 

Posts:6,147
Registered: 11/9/00
Re: reliable semaphore implementation question  
Jun 27, 2004 9:01 AM (reply 1 of 3)



 
It may catch the InterruptedException outside the monitor but the exception actually occurs in the wait - which is inside the monitor.
 

Posts:835
Registered: 2/12/01
Re: reliable semaphore implementation question  
Jun 27, 2004 9:14 AM (reply 2 of 3)



 
One more question on the example. The author catches InterruptedException in the acquire() in order to send notification to one of the waithing threads. He uses notify() in semaphore's release() instead of notifyAll() in order to reduce context switching overhead. On the notification, one of the waiting threads is waked up and acquires a permit. Author claims that this notify() in catch clause is neeed to avoid loosing notification. That is, if one notified thread exits on exception without taking a permit, we should notify other waiting threads. However, the thread exits on InterruptedException only if it is waiting; that is, it is not notified. Therefore, I do not see the reason for exception handler in the acquire().

IMO, the following code looks neater:
public void synchronized acquire() throws InterruptedException {    if (Thread.interrupted()) throw new InterruptedException();    if (permits == 0) wiat(); // no loop is need    permit--;           // we get here only on permit release notification }
 

Posts:835
Registered: 2/12/01
Re: reliable semaphore implementation question  
Jun 27, 2004 9:27 AM (reply 3 of 3)



 
It may catch the InterruptedException outside the monitor but the exception actually occurs in the wait - which is inside the monitor.

What do you mean by that? I'm asking what if we interrupt a therad between interrupted check in the first line of acquire() and wait loop? If thread would be interrupted by level (that is, once interrupted it enters wait() and immediately gets InterruptedException) then there is no need to have the check. Otherwise, an interrupted thread still may still enter the wait() loop. In any case, the first line check for interrupted flag is useless.
 
This topic has 3 replies on 1 page.