Re: Block in synchronized mathod
From: Tilman Bohn (myfirstname_at_gmx.net)
Date: 02/23/05
- Next message: Maxim Kasimov: "task sheduling"
- Previous message: blmblm_at_myrealbox.com: "Re: How does a thread call a synchronized method??"
- In reply to: Tony Dahlman: "Re: Block in synchronized mathod"
- Next in thread: Tony Dahlman: "Re: Block in synchronized mathod"
- Reply: Tony Dahlman: "Re: Block in synchronized mathod"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 23 Feb 2005 11:33:32 GMT
[Some re-wrapping of quoted text ahead]
In message <421C3EA4.3040109@jps.net>,
Tony Dahlman wrote on Wed, 23 Feb 2005 08:28:23 GMT:
[...]
> Clearly I was on the wrong track thinking this was one of those
> business "issues" with the tool and JVM producers. Curiosity is
> undiminished, however. Any idea how much efficiency would be lost if
> the Java spec didn't permit spurious wakeups?
Sorry, no idea. I've never investigated it since the loop is the
correct and robust way to do it anyway.
[...]
> seemed to require it some 7 to 10 years ago. In one case, however,
> the while() was just checking if the application was ready to
> complete. (There was no "done" variable for a thread, only an
> "allDone" variable for the application.) Was that right or should I
> rewrite it with a tighter loop? As I see it, a spurious wakeup would
> do nothing....
Looks ok to me at first glance, but I don't have time to look at it in
detail right now, so don't depend on my word here. Come to think of it,
don't depend on my word in any case. It's not like I haven't produced my
share of deadlocks and livelocks in my time. :-)
[...]
> But I'm also curious about those "superflous condition broadcasts or
> signals on the same condition". Where are those coming from in a Java
> program that (rarely) might produce them?
This means code executed in another thread that notifies threads
waiting on that same lock, without having altered state to make the
predicate hold. That could be either by accident (coding error), by
malice (third party code), or possibly by design. In many cases bad
design I suppose, but using coarse-grained monitors when you're waiting
for different but supposedly somehow related conditions can sometimes
make sense. For instance, maybe the notifying code can't be sure exactly
which of those related predicates have changed at the time it notifies
waiters. Then it would be natural to wake up all threads waiting on that
lock under these different guards.
> Is some of the underlying
> code of the listener-event construct, which is such a plus for Java,
> doing that, even if rarely?
[...]
Nah, just some other application code. You never know who might send
you a signal, or when, even if you keep very tight wraps on your monitor
(remember you can use any old Object as a monitor).
-- Cheers, Tilman `Boy, life takes a long time to live...' -- Steven Wright
- Next message: Maxim Kasimov: "task sheduling"
- Previous message: blmblm_at_myrealbox.com: "Re: How does a thread call a synchronized method??"
- In reply to: Tony Dahlman: "Re: Block in synchronized mathod"
- Next in thread: Tony Dahlman: "Re: Block in synchronized mathod"
- Reply: Tony Dahlman: "Re: Block in synchronized mathod"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
