File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Threads and Synchronization and the fly likes InterruptedException.. cause and way of prevention.. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "InterruptedException.. cause and way of prevention.." Watch "InterruptedException.. cause and way of prevention.." New topic
Author

InterruptedException.. cause and way of prevention..

V Chauhan
Ranch Hand

Joined: Nov 15, 2002
Posts: 70
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.
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
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...


"I'm not back." - Bill Harding, Twister
Nathaniel Stoddard
Ranch Hand

Joined: May 29, 2003
Posts: 1258
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.


Nathaniel Stodard<br />SCJP, SCJD, SCWCD, SCBCD, SCDJWS, ICAD, ICSD, ICED
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
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

Joined: Nov 15, 2002
Posts: 70
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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: InterruptedException.. cause and way of prevention..