[concurrency-interest] Await...Signal - Catching IllegalMonitorStateException???

Richie.Jefts at APCC.com Richie.Jefts at APCC.com
Mon Oct 23 14:27:36 EDT 2006


You need to surround condition.signal() with lock/unlock. This is similar 
to surrounding object.notify() with a synchronized block.

You may want to consider using the ExecutorService. For example,

Future future = executorService.submit(parser);
try {
        future.get(4L, TimeUnit.SECONDS);
}
catch (ExecutionException e) {
        // handle...
}
catch (TimeoutException e) {
        future.cancel(true);
}

And the parser can check Thread.isInterrupted() every so often for 
cancellation in case the timeout has occurred. Java Concurrency in 
Practice has some nice examples.
 
richie




"David Harrigan" <dharrigan at gmail.com> 
Sent by: concurrency-interest-bounces at cs.oswego.edu
10/23/2006 12:46 PM

To
concurrency-interest at cs.oswego.edu
cc

Subject
[concurrency-interest] Await...Signal - Catching 
IllegalMonitorStateException???






Hi,

Firstly let me say that I'm really happy to find this list. I find 
threading
difficult, but I'm trying to get to trips with it as best I can, and I'm 
sure
this list will help my minisule understanding...

Okay, I am trying to get to trips with the concurrency features in Java
1.5, and I've got an issue that I'm trying to understand. I have this
basic program structure...

....
....
private Lock lock = new ReentrantLock(); 
private Condition condition = lock.newCondition();
....
Parser parser = new Parser(condition);
lock.lock();
try {
    new Thread(parser).start();
    if(!condition.await(2000, TimeUnit.MILLISECONDS)) { 
        if(parser.isReading()) {
            if(!condition.await(2000, TimeUnit.MILLISECONDS)) {
                setTimedOutWhilstReading(true);
            }
        }
        setTimedOutWhilstWaitingForResponse(true); 
    }
} catch(InterruptedException e) {
} finally {
  lock.unlock();
}

then in Parser I have this...

....
....
public Parser(final Condition condition) {
    this.condition = condition; 
}

public void run() {
    try {
       synchronized(this) {
           wait(10000); // <--------- simulate this parser taking 10 
seconds reading, causing timeout in calling thread
       }
    } catch (InterruptedException e) { 
    }

    try {
        condition.signal();
    } catch(IllegalMonitorStateException e) {
    }
}



Okay, let me try and explain:

I have a thread (X) that creates a parser (Y). X has to check for a few 
things, 
namely that Y hasn't timed out waiting for a response (the first await in 
X) then
if it has timed out X checks to see if Y has started to parse a response. 
I've
simulated in Y that Y takes 10 seconds to do it's business (ignorning a 
response read etc..I'm just interested in overall time at this point). 

Now, in X, because the two awaits have timed out (total ~4 seconds), X has
moved on and exited out of it's run() and the calling thread of X does 
some 
extra things...etc...

But, because X has moved on, when I call condition.signal() I have to 
catch
an IllegalMonitorStateException! This seems to me a bit "strange." I can 
perhaps
hazzard a guess that because the lock (it's condition) in X no longer 
exists, then 
calling condition.signal() in Y causes this, but my question is - is this 
correct? Do
I have to do this? Am I not tripping out?

Now, the reason I have condition.signal() is that in the version of Parser 
that 
does the parsing and returns in < 4 seconds, then X which is sitting in an
await state, calling condition.signal() is the right thing to do - I have 
to tell X
that Y is finished....

What I'm trying to understand is what happens if Y takes a long long time, 
what 
I have to do to X (and Y) for the states to be properly managed....

I hope this is clear? If not, then please do ask me for clarification...

Thanks so so much, and I look forward to participating in this list! 

-=david=-_______________________________________________
Concurrency-interest mailing list
Concurrency-interest at altair.cs.oswego.edu
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20061023/edf0c028/attachment.html 


More information about the Concurrency-interest mailing list