• Post Reply Bookmark Topic Watch Topic
  • New Topic

wait(long timeout)  RSS feed

 
pr po
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
How do you distinguish whether a thread had been notified
or the timeout expired when the thread is blocking in wait(long timeout) mode.
based on the type of event ( time out or notification) different things need to happen in my case.
any help would be grateful
thanks
 
Paul Caudle
Ranch Hand
Posts: 64
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey, I'm not sure of any technical way to differentiate between the two, but you could always just use a timer thread that starts just before you call the wait (long). Check the interval passed in the timer thread after the wait returns against the interval passed to the wait...
Or you could capture the time before the wait and the time after the wait and compare them. If the difference is less than the timeout you know that it was notified.

this does have a tiny interval of time in which the wait may have returned just before its interval was complete but close enough to completion that the time taken to execute the next line of code causes the comparison of the two numbers to be off. So it's not quite a perfect solution...
That was a heap of complicated writing, so if you don't quite get it or think it's a pile of garbage, just let me know.
If you do find a perfect solution, let me know...it would be of great use.
Hope that helps,
Paul

[This message has been edited by Paul Caudle (edited November 03, 2000).]
 
Jerry Pulley
Ranch Hand
Posts: 221
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paul,
That's good lateral thinking. It might just work. There would have to be very few threads in the system, or time slicing could throw it off. Also, the shorter the timeout the greater the chance that the delay until the time check (whether from time slicing or just time to execute the code) will put you over the limit. The timer solution might be good enough if you can tolerate the occasional wrong choice.
pr po,
It'd be better to architect a solution that didn't require knowledge of timeout vs. notification, but here's another possibility if you're committed to the current design. Derive a new class from <code>Thread</code> with a flag for timeout vs. notification. Create another class with an overloaded version of <code>wait</code> that takes an instance of the <code>Thread</code> derivative as an argument and registers it. This class will also need an overridden <code>notify</code> that sets the flag in the registered <code>Thread</code> derivative appropriately. Use the second class as your monitor (object to lock on).
Now, I've never tried this and I can already see some implementation difficulties, but if you can make it work you'll have a definite solution.
jply
 
Jerry Pulley
Ranch Hand
Posts: 221
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Or maybe you could interrupt the waiting thread instead of notifying it, so it could check its interrupted status to find out how it left the wait set...
*#%@ it, why'd you have to post that question? I'm having trouble leaving it alone...
jply
 
Paul Caudle
Ranch Hand
Posts: 64
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
LOL, Jerry, I'm with you...this is hard to just let go...I like your ideas, though, but I try to use the least number of flags possible so I like your interrupt approach much more.
 
pr po
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks guys for the responses, I am with you guys on using interrupt rather than notify....I am yet to implement it, till now i've used notify but using interrupt is a better solution.
any more ideas would be great. thanks again
 
Jerry Pulley
Ranch Hand
Posts: 221
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Guys,
The advantage of deriving new thread and monitor classes is that you can continue to organize your synchronization as if nothing had changed. If you go with the interrupt approach, be aware that when a waiting thread is interrupted, it throws an <code>InterruptedException</code> as soon as it begins to run. When it throws this exception, its internal interrupt flag is automatically cleared, so <code>interrupted</code> and <code>isInterrupted</code> will return <code>false</code>. You'll have to tell how it left the wait set by whether the exception is thrown.
As for the derivation approach, <code>notify</code> won't work, it'll have to be <code>notifyAll</code>.
jply

[This message has been edited by Jerry Pulley (edited November 08, 2000).]
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!