• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

InterruptedException.. cause and way of prevention..

 
Ranch Hand
Posts: 70
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
I have a simple piece of code where I have a boolean flag which is set/accessed by multiple threads. If it is set to false, than the threads wait until one thread sets it to true.

public synchronized void checkFlag() throws InterruptedException {
if(! myFlag() ){
wait();
}
}
public synchronized void setFlag(myNewFlag) {
myFlag = myNewFlag;
if(myFlag) {
notifyAll();
}
}

This code works fine.. but in some rare runs, the method checkFlag throws an InterruptedException.
Can someone explain me, why is this exception thrown and what can be done to prevent it.
Or is it a safe idea to put an empty catch block for this exception and ignore it.
Thanks in Advance,
Basu.
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If it is set to false, than the threads wait until one thread sets it to true.
Your code doesn't wait until it's set to true - it just waits until it's notified. If someone calls setFlag(false) this will notify too, even though the flag is false. You should probably replace
with
This code works fine.. but in some rare runs, the method checkFlag throws an InterruptedException.
Can someone explain me, why is this exception thrown and what can be done to prevent it.

Most likely some other code somewhere is calling interrupt() on your thread. Do you call interrupt() anywhere? Are you running other software which might be calling it? It wouldn't surprise me if some J2EE environments have thread pooling tools which might try to monitor the activity of their threads and interrupt them in certain circumstances - but I don't know details here, I'm just guessing.
Or is it a safe idea to put an empty catch block for this exception and ignore it.
Well InterruptedException is one of the few cases where this may be a safe strategy - but usually only if you know what other part of the code is calling interrupt(), and you know that it's OK. If you're not sure, I would say that you should at least log the exception so that you have the ability to investigate it later if necessary. If you hide the exception by ignoring it completely, you can make things much harder for yourself later.
You also need to decide just what behavior you need from this method. Does the method absolutely need to wait for flag to be true? Or if there's an interruption, should the method exit early (even though flag is false)? You might have code like this:

Here the InterruptedException allows the method to exit if flag is false. Proably this is a bad idea - if you want an early exit in this case, just allow the exceptino to be thrown; don't catch it. Because someone else (or even you) will probably assume that flag is true after this method completes, and it may not be. Or:

Here it doesn't matter if some other thread tries to interrupt; we're going to keep waiting until the flag is true, period. Which may be what you need, of may not. This is the sort of thing you need to decide though...
 
Ranch Hand
Posts: 1258
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You can always use Thread.interrupted() to determine if the thread was interrupted and thrown an InterruptedException -- then you can take whatever action you want to make things consistent.
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I don't think that will help. If an InterruptedException is thrown, then interrupted() and isInterrupted() will return false unless another interruption occurs. Because the InterruptedException is already a clear signal that an interruption has occurred. The boolean status is only used in situations where the JVM can't throw an InterruptedException, if an interrupt occurs while you're executing some method which does not declare that it can throw InterruptedException. You can nonetheless test for interruptions using interrupted() or isInterrupted(). If, after the interruption, you subsequently enter a wait() or sleep(), (and if you didn't call interrupted() which would clear the interrupted status) then the wait() or sleep() will immediately throw an InterruptedException and clear the interrupted status, which means that if you then call interrupted() or isInterrupted() they return false. Basically, if you're using any method which can throw InterruptedException, don't bother testing interrupted()/isInterrupted() - just catch the exception.
 
V Chauhan
Ranch Hand
Posts: 70
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the info Jim.


It wouldn't surprise me if some J2EE environments have thread pooling tools which might try to monitor the activity of their threads and interrupt them in certain circumstances -


Ours is a web application running on WebLogic 7.0. Any ideas, why WebLogic might be invoking the interrupt method?
Thanks,
Basu.
 
reply
    Bookmark Topic Watch Topic
  • New Topic