Home > Archive > Java Help > February 2005 > How does a thread call a synchronized method??
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
How does a thread call a synchronized method??
|
|
| bunallo 2005-02-19, 3:58 am |
| If a thread needs to call the methods notify() and wait() it has to own the
lock. The only way it can own the lock is by invoking a synchronized method.
But typically the synchronized methods lies in another class and not in the
threads themselves. My question is then:
How can a thread invoke these synchronized methods when they are not in the
thread??
| |
| JTMOBAP 2005-02-19, 3:58 am |
| What to do here?
Alright..
If you need to call wait(), then you put that into your synchronized
method. the method wait is derived from the clas Object, not Thread., so
you it doesn't need to be a thread object. You call wait to give the
other threads a chance to run when a thread is executing code inside a
synchronized method. This method gives up the 'lock' gained by the thread
accessing the synchronized method, and passes control to the next random
thread.
As for notify., you generally do not want to call notify(), because it
wakes any one thread, and the thread you may want to wake will not run.
So you will want to instead call notifyAll(), wich notifies all waiting
threads, and the compiler picks which thread to wake. If you have a
waiting thread that you want to wake before others,, give it a priority
higher than the other threads. Default is 5, I believe.
You generally put the wait method in some loop, to check for a condition
that it would need to wait to happen before it continues. When the thread
wakes, it checks the condition, and if it is still true (or false,
whichever) then it calls wait() again. When it checks out, it skips over
the wait method, and you finish the synchronized portion of that method,
and then call notifyAll().
Multithreading can be confusing at times, but you can almost completely
control the flow of the threads by assigning priorities. Generally,
unless something will produce an error, you don't even need to worry about
calling wait() or notify()., because they can cause problems with your
threads.
By the way, notifyAll() should be called on the same object. In other
words, another thread must test out past your wait() method and then call
notifyAll() to wake the waiting threads.
I hope that helped out a little. :)
| |
| JTMOBAP 2005-02-19, 3:58 am |
| A thread invokes a synchronized method when it calls that method. The
method can be in any class. When the thread executes the code in the
synchronized method, it owns 'that lock'. Any other thread can also call
the synchronized method., but if another thread owns the lock, then these
threads cannot continue, and they block. If the synchronized method
contains code that could block your thread or your thread needs to wait
for something else to happen, you then call wait() and give the other
threads a chance to run the same synchronized method. Then when those
threads work, they call notifyAll() within that method to wake the waiting
threads. I think that should make it a little more clearer.
| |
| blmblm@myrealbox.com 2005-02-19, 3:58 am |
| In article < e1aa34536aaf0d7efdf69a349731bf6c@localho
st.talkaboutprogramming.com>,
JTMOBAP <mo_mail_jeremiah@yahoo.com> wrote:
[ snip ]
>Multithreading can be confusing at times, but you can almost completely
>control the flow of the threads by assigning priorities.
But you probably shouldn't. Quoting from Sun's tutorial at
http://java.sun.com/docs/books/tuto.../priority.html:
Rule of thumb: At any given time, the highest priority thread is
running. However, this is not guaranteed. The thread scheduler may
choose to run a lower priority thread to avoid starvation. For this
reason, use thread priority only to affect scheduling policy for
efficiency purposes. Do not rely on it for algorithm correctness.
--
| B. L. Massingill
| ObDisclaimer: I don't speak for my employers; they return the favor.
| |
| bunallo 2005-02-19, 8:57 am |
|
"JTMOBAP" <mo_mail_jeremiah@yahoo.com> skrev i en meddelelse
news:df5051b4de58ab3c45fc22129c45370a@lo
calhost.talkaboutprogramming.com...
> A thread invokes a synchronized method when it calls that method. The
> method can be in any class. When the thread executes the code in the
> synchronized method, it owns 'that lock'. Any other thread can also call
> the synchronized method., but if another thread owns the lock, then these
> threads cannot continue, and they block. If the synchronized method
> contains code that could block your thread or your thread needs to wait
> for something else to happen, you then call wait() and give the other
> threads a chance to run the same synchronized method. Then when those
> threads work, they call notifyAll() within that method to wake the waiting
> threads. I think that should make it a little more clearer.
>
If I have:
class A extends Thread{
private B bb;
public A(B b){
bb = b;
}
public void run(){
bb.waitfor();
}
}
class B{
public synchronized void waitfor(){
try{
wait();
}
catch(InterruptedException e){}
}
}
class StartThread{
public static void main(String[] args) {
B b = new B();
A a = new A(b);
a.start();
}
}
then my thread A should be set to wait when it is started right?
| |
| Steve Horsley 2005-02-19, 3:58 pm |
| bunallo wrote:
> If a thread needs to call the methods notify() and wait() it has to own the
> lock. The only way it can own the lock is by invoking a synchronized method.
>
> But typically the synchronized methods lies in another class and not in the
> threads themselves. My question is then:
>
> How can a thread invoke these synchronized methods when they are not in the
> thread??
>
>
Quite often the wait() and notify() methods will be called from another method
of the same object. For instance, a queue:
class Queue {
List items = new LinkedList();
public synchronized void add(Object o) {
items.put(o);
notify(); // wake one thread if anyone is waiting
}
public synchronized Objec get() {
if(items.size > 0) {
return items.remove(0);
}
wait();
return items.remove(0);
}
}
A synchronized method is shorthand for a code block that is
synchronized(this), so the object being locked is the Queue instance.
It would be possible to add an oblect to the queue from another class
like this:
synchronized(myQueue) {
myQueue.add(myObject);
myQueue.notify();
}
However, I do not feel comfortable doing it in this case because I
feel that the List belongs to the queue and should really be a
private implementation detail. But it should give you the idea.
Steve
| |
| Tony Dahlman 2005-02-19, 8:59 pm |
| JTMOBAP wrote:
> A thread invokes a synchronized method when it calls that method. The
> method can be in any class. When the thread executes the code in the
> synchronized method, it owns 'that lock'. Any other thread can also call
> the synchronized method., but if another thread owns the lock, then these
> threads cannot continue, and they block. If the synchronized method
> contains code that could block your thread or your thread needs to wait
> for something else to happen, you then call wait() and give the other
> threads a chance to run the same synchronized method. Then when those
> threads work, they call notifyAll() within that method to wake the waiting
> threads. I think that should make it a little more clearer.
>
class Monitor {
public synchronized void waitJustAMinute() {
try{
wait( 60000 );
} catch( InterruptedException ie) { }
}
public synchronized void wakeUp() {
notify();
}
}
class Thready implements Runnable {
Monitor monitorRef;
public Thready( Monitor monitorRef ) {
this.monitorRef = monitorRef;
}
public void run() {
// do something, then call the synchronized method
monitorRef.waitJustAMinute();
// this thread is now blocked till someone else
// calls monitorRef.wakeUp(), or till time runs out.
// do more things, then exit
return;
}
}
-----------------------------------------------
This is just to illustrate the answer to the OP's question. A second
or third instance of Thready could be forced to wait up to 2 or even 3
minutes. Do you see that, OP?
Oh, and do *not* put wait() in a loop "generally":
-------------------------------------
while( ! done ) {
wait();
}
---------------------------------------
....obviously, because there go all your CPU cycles. That's called
polling for a condition. Instead, just take advantage of java threads
and careful coding to block your waiting threads until conditions are
right. When they are right, just call your wakeUp() method.
For a more robust example, see:
http://pws.prserv.net/ad/programs/TaskScheduler.java
The example in the link shows how to use a monitor to control precisely the
order of execution of multiple threads, in which case you can
use notify() (no need for notifyAll()) and be certain of what
will happen.
HTH Tony Dahlman
--
---------------------------------------
nospam, I've had it, thanks.
| |
| Tony Dahlman 2005-02-19, 8:59 pm |
| JTMOBAP wrote:
> A thread invokes a synchronized method when it calls that method. The
> method can be in any class. When the thread executes the code in the
> synchronized method, it owns 'that lock'. Any other thread can also call
> the synchronized method., but if another thread owns the lock, then these
> threads cannot continue, and they block. If the synchronized method
> contains code that could block your thread or your thread needs to wait
> for something else to happen, you then call wait() and give the other
> threads a chance to run the same synchronized method. Then when those
> threads work, they call notifyAll() within that method to wake the waiting
> threads. I think that should make it a little more clearer.
>
public class Monitor {
public synchronized void waitJustAMinute() {
try{
wait( 60000 );
} catch( InterruptedException ie) { }
}
public synchronized void wakeUp() {
notify();
}
}
class Thready implements Runnable {
Monitor monitorRef;
public Thready( Monitor monitorRef ) {
this.monitorRef = monitorRef;
}
public void run() {
// do something, then call the synchronized method
monitorRef.waitJustAMinute();
// this thread is now blocked till someone else
// calls monitorRef.wakeUp(), or till time runs out.
// do more things, then exit
return;
}
}
------------------------------------------
This is just to illustrate the answer to the OP's question. A second or third
instance of Thready could be forced to wait longer, up to 3 minutes....
Oh, and do *not* put wait() in a loop "generally":
while( ! done ) {
wait();
}
....because there go all your CPU cycles. That's called polling for a condition.
Instead, take advantage of java threads and careful coding to block your waiting
threads. In this example, just call wakeUp() when conditions are right.
For one simple way to precisely control the order of execution of multiple
threads, you might want to look at:
http://pws.prserv.net/ad/programs/TaskScheduler.java
In examples like the one in this link, notify(), and not notifyAll(), is all
you need.
Finally, to agree with blmblm, don't use thread priorities for this.
HTH --Tony Dahlman
--
---------------------------------------
nospam, I've had it, thanks.
| |
| blmblm@myrealbox.com 2005-02-20, 4:03 am |
| In article <4217D8AE.20408@jps.net.invalid>,
Tony Dahlman <adahlman@jps.net.invalid> wrote:
>JTMOBAP wrote:
>
[ snip ]
>Oh, and do *not* put wait() in a loop "generally":
> while( ! done ) {
> wait();
> }
>...because there go all your CPU cycles. That's called polling for a condition.
>Instead, take advantage of java threads and careful coding to block your waiting
>threads. In this example, just call wakeUp() when conditions are right.
Um -- no. "There go all your CPU cycles" applies if you're "busy
waiting" (repeatedly checking a condition until it has the value you
want) -- but with the "wait()", the above loop isn't doing that, is it?
The above loop is the method that's generally recommended as the
safest way to wait until "done" becomes true, with a "notifyAll" in the
method that makes "done" true. A single "if (something) wait()" and
"notify()" can work, but you have to be sure that "notify()" is *only*
called when "done" becomes true, and nothing else can happen to make
"done" false between then and when the waked-up thread reacquires
the lock and continues execution. I can't think of a great example in
which not using a loop would cause things to go awry, so I'll fall
back on the "argument from authority" -- the loop approach is what
Sun's tutorial recommends.
[ snip ]
> http://pws.prserv.net/ad/programs/TaskScheduler.java
>In examples like the one in this link, notify(), and not notifyAll(), is all
>you need.
Not having time to follow this link and review the code -- could be.
"notify" rather than "notifyAll" can work. But IMO it requires a
degree of understanding/caution that someone new to multithreading
might not have. My two cents' worth.
--
| B. L. Massingill
| ObDisclaimer: I don't speak for my employers; they return the favor.
| |
| Tony Dahlman 2005-02-21, 3:59 am |
| blmblm@myrealbox.com wrote:
> In article <4217D8AE.20408@jps.net.invalid>,
> Tony Dahlman <adahlman@jps.net.invalid> wrote:
>
>
>
> [ snip ]
>
>
>
>
> Um -- no. "There go all your CPU cycles" applies if you're "busy
> waiting" (repeatedly checking a condition until it has the value you
> want) -- but with the "wait()", the above loop isn't doing that, is it?
>
> The above loop is the method that's generally recommended as the
> safest way to wait until "done" becomes true, with a "notifyAll" in the
> method that makes "done" true. A single "if (something) wait()" and
> "notify()" can work, but you have to be sure that "notify()" is *only*
> called when "done" becomes true, and nothing else can happen to make
> "done" false between then and when the waked-up thread reacquires
> the lock and continues execution. I can't think of a great example in
> which not using a loop would cause things to go awry, so I'll fall
> back on the "argument from authority" -- the loop approach is what
> Sun's tutorial recommends.
>
> [ snip ]
>
>
>
>
> Not having time to follow this link and review the code -- could be.
> "notify" rather than "notifyAll" can work. But IMO it requires a
> degree of understanding/caution that someone new to multithreading
> might not have. My two cents' worth.
>
Oops, this is true, of course. An actual example of polling would be:
while( ! done ) {
wait(100);
}
This is tricky, though. My amended example code (above) clearly wastes CPU cycles
by polling every 100 msec, but not all of them. Agreed.
And you are careful to say that notify() *must* be called by the method that
sets the variable "done" to true. OTOH people new to multi-threading would
probably not know that they should make that variable private and use a
method to change it, let alone a synchronized method.
As you can tell, I'm averse to polling for a condition, so much so that I
avoid code like what is recommended in the Sun tutorial without
even thinking about it. After all, if a newbie starts thinking that code
like:
while( ! done ) {
...
}
....is as okay in Java as it is in BASIC, they might get the wrong idea.
As for "argument from authority", I have always preferred evidence-based
to eminence-based information. (That's why I supplied code.)
Regards (with all due respect),
Tony Dahlman
PS - The code I posted was discussed 5 or 10 years ago in this group or in
c.l.j.p. Another professor pointed out that I didn't really have to pass
the reference to the thread, that making the synchronized methods in the
monitors "static" would do just fine. He/she was right.
--
---------------------------------------
nospam, I've had it, thanks.
| |
| blmblm@myrealbox.com 2005-02-21, 9:00 pm |
| In article <421959C1.6070708@jps.net.invalid>,
Tony Dahlman <adahlman@jps.net.invalid> wrote:
>blmblm@myrealbox.com wrote:
>
>condition.
>your waiting
[ snip ]
[color=darkred]
>Oops, this is true, of course. An actual example of polling would be:
> while( ! done ) {
> wait(100);
> }
>This is tricky, though. My amended example code (above) clearly wastes
>CPU cycles
>by polling every 100 msec, but not all of them. Agreed.
>
>And you are careful to say that notify() *must* be called by the method that
>sets the variable "done" to true. OTOH people new to multi-threading would
>probably not know that they should make that variable private and use a
>method to change it, let alone a synchronized method.
Actually what I'm saying is a little stronger than that: What I'm
saying is that "done" must be set "true" in the same synchronized
method/block as the "notify" -- *and* it must be the case that "done"
stays true until the thread waked up by "notify" reacquires the lock
and continues execution. To me it seems safer to re-test "done"
(as the loop approach does) before continuing execution. I'm not
coming up with a good example of how one could in trouble by not
re-testing -- perhaps something where there's more than one condition
involved, so the waked-up thread can't be sure that the condition *it*
was waiting for has become true.
>As you can tell, I'm averse to polling for a condition, so much so that I
>avoid code like what is recommended in the Sun tutorial without
>even thinking about it. After all, if a newbie starts thinking that code
>like:
> while( ! done ) {
> ...
> }
>...is as okay in Java as it is in BASIC, they might get the wrong idea.
Maybe we have to agree to disagree here.
My argument in favor of the loop approach would be that it guarantees
atomicity (testing the condition and then doing the code to be executed
if it's true) in a way that you otherwise don't get.
And there do seem to be a lot of ways for newbies to get wrong ideas.
I'm not sure how to fix that ....
>As for "argument from authority", I have always preferred evidence-based
>to eminence-based information. (That's why I supplied code.)
I'll agree that arguments from authority aren't as compelling as those
from more direct evidence, but IMO they're worth *something*. <shrug>
>Regards (with all due respect),
Likewise.
>
>PS - The code I posted was discussed 5 or 10 years ago in this group or in
>c.l.j.p. Another professor pointed out that I didn't really have to pass
>the reference to the thread, that making the synchronized methods in the
>monitors "static" would do just fine. He/she was right.
I'll try to track down the earlier discussion, and also review your
code. Getting wait/notify exactly right is something I often wish
I felt more confident about, so this might be time ....
--
| B. L. Massingill
| ObDisclaimer: I don't speak for my employers; they return the favor.
| |
| blmblm@myrealbox.com 2005-02-21, 9:00 pm |
| In article <37ukqtF5hm8gqU1@individual.net>, <blmblm@myrealbox.com> wrote:
>In article <421959C1.6070708@jps.net.invalid>,
[ should "wait" be preceded by "if" or "while" ]
Following up on my own post .... In another current thread (subject
"Block in synchronized method"), someone is making a case for the loop
idiom. Possibly something to look at before going further? the person
insisting on "wait" says something about spurious wakeups, which sounds
like something to read up on ....
--
| B. L. Massingill
| ObDisclaimer: I don't speak for my employers; they return the favor.
| |
| Tilman Bohn 2005-02-21, 9:00 pm |
| In message <37ukqtF5hm8gqU1@individual.net>,
blmblm@myrealbox.com wrote on 21 Feb 2005 17:41:49 GMT:
[...]
> Actually what I'm saying is a little stronger than that: What I'm
> saying is that "done" must be set "true" in the same synchronized
> method/block as the "notify"
This part is not actually necessary. If the predicate is a valid guard
(i.e., a necessary and _sufficient_ precondition for continuing), then
it doesn't really matter by what means or from what threads the relevant
state has been changed. And for wait/notify to be safe at all in the
presence of spurious wakeups, you _must_ use a valid guard. Otherwise
you're toast anyway, see below.
> -- *and* it must be the case that "done"
> stays true until the thread waked up by "notify" reacquires the lock
> and continues execution.
Yes, this is precisely the reason for using the loop.
> To me it seems safer to re-test "done"
> (as the loop approach does) before continuing execution.
Right. Just because someone changed the condition to true before
notifying you, it is not safe to assume it will still be true once you
actually wake up and resume execution within the monitor.
> I'm not
> coming up with a good example of how one could in trouble by not
> re-testing -- perhaps something where there's more than one condition
> involved, so the waked-up thread can't be sure that the condition *it*
> was waiting for has become true.
That is one scenario. Another is someone erroneously (or maliciosly)
calling notify() at a time when the condition that was false when you
went to sleep is _still (or again, it doesn't matter) false_. But even
if the notify() call was correct, there is a delay between the time the
thread calling notify() relinquishes the lock and the thread wait()ing
reacquires it. As soon as the lock is released, _any_ thread trying to
acquire it has a chance of doing so. There is no way to guarantee it
will be the one being notified. But if another thread gets the lock
first, it may influence the result of the guard predicate. So by the
time it exits the monitor, and your wait()ing thread finally enters it,
there is absolutely no way to be sure the guard is still true. So: time
to re-test, and if it is indeed now false, go back to wait()ing.
The final nail in the coffin of the loop-less wait() is spurious
wakeups, which are a result of the native implementation of most (all?)
threading libraries, which ultimately underly the Java threading API.
`Spurious wakeup' simply means that a wait()ing thread may, at any time,
and for no real reason at all, spontaneously wake up as if notified. See
for example the final three paragraphs in the Rationale section of this
pthreads man page:
http://makeashorterlink.com/?L1072278A
[...]
> My argument in favor of the loop approach would be that it guarantees
> atomicity (testing the condition and then doing the code to be executed
> if it's true) in a way that you otherwise don't get.
[...]
Sort of. The missing atomicity of the operation `notifying thread
relinquishes lock, waiting thread acquires it' is indeed one of the
problems. And the guarded wait loop is a way to at least get `as-if'
atomicity, that is, the rest of the code can act as if that monitor
transfer were truly atomic. So while you don't get actual atomicity, you
do get atomicity semantics in that respect.
--
Cheers, Tilman
`Boy, life takes a long time to live...' -- Steven Wright
| |
| blmblm@myrealbox.com 2005-02-22, 8:58 am |
| In article <37qkqbF5gv31nU1@individual.net>, <blmblm@myrealbox.com> wrote:
>In article <4217D8AE.20408@jps.net.invalid>,
>Tony Dahlman <adahlman@jps.net.invalid> wrote:
>
>[ snip ]
>
>condition.
>your waiting
>
>Um -- no. "There go all your CPU cycles" applies if you're "busy
>waiting" (repeatedly checking a condition until it has the value you
>want) -- but with the "wait()", the above loop isn't doing that, is it?
>
>The above loop is the method that's generally recommended as the
>safest way to wait until "done" becomes true, with a "notifyAll" in the
>method that makes "done" true. A single "if (something) wait()" and
>"notify()" can work, but you have to be sure that "notify()" is *only*
>called when "done" becomes true, and nothing else can happen to make
>"done" false between then and when the waked-up thread reacquires
>the lock and continues execution. I can't think of a great example in
>which not using a loop would cause things to go awry, so I'll fall
>back on the "argument from authority" -- the loop approach is what
>Sun's tutorial recommends.
>
>[ snip ]
>
>
>Not having time to follow this link and review the code -- could be.
>"notify" rather than "notifyAll" can work. But IMO it requires a
>degree of understanding/caution that someone new to multithreading
>might not have. My two cents' worth.
Having skimmed the referenced example (TaskScheduler.java):
I assumed in my reply that it did something like "if (condition)
wait();" where I would write "while (condition) wait();", but
it doesn't. So a "never mind" may be in order. In the example,
"notify" does seem okay given that -- if I'm understanding the code
right -- only a single thread would ever be waiting?
--
| B. L. Massingill
| ObDisclaimer: I don't speak for my employers; they return the favor.
| |
| blmblm@myrealbox.com 2005-02-22, 8:58 am |
| In article <slrnd1kb5h.8o5.myfirstname@urizen.tilmanbohn.com>,
Tilman Bohn <myfirstname@gmx.net> wrote:
>In message <37ukqtF5hm8gqU1@individual.net>,
>blmblm@myrealbox.com wrote on 21 Feb 2005 17:41:49 GMT:
>
>[...]
>
> This part is not actually necessary. If the predicate is a valid guard
>(i.e., a necessary and _sufficient_ precondition for continuing), then
>it doesn't really matter by what means or from what threads the relevant
>state has been changed. And for wait/notify to be safe at all in the
>presence of spurious wakeups, you _must_ use a valid guard. Otherwise
>you're toast anyway, see below.
>
>
> Yes, this is precisely the reason for using the loop.
Which was the point I was trying to make. Agreed that setting "done"
to true in the same synchronized method/block as the "notify" is
not necessary. Post in haste, repent at leisure ....
[ snip ]
> The final nail in the coffin of the loop-less wait() is spurious
>wakeups, which are a result of the native implementation of most (all?)
>threading libraries, which ultimately underly the Java threading API.
>`Spurious wakeup' simply means that a wait()ing thread may, at any time,
>and for no real reason at all, spontaneously wake up as if notified. See
>for example the final three paragraphs in the Rationale section of this
>pthreads man page:
>
>http://makeashorterlink.com/?L1072278A
Yipes. I find this caveat/disclaimer mildly shocking -- it seems
at odds with my idea of a proper specification for a threads library
-- but perhaps this reaction just shows that I don't understand the
relevant performance considerations. But it does clarify why spurious
wakeups might be considered acceptable.
[ snip ]
Glad someone with a more complete understanding (and better list
of references) followed up ....
--
| B. L. Massingill
| ObDisclaimer: I don't speak for my employers; they return the favor.
| |
| Tilman Bohn 2005-02-22, 8:58 am |
| In message <3809g3F5k61ucU1@individual.net>,
blmblm@myrealbox.com wrote on 22 Feb 2005 08:40:35 GMT:
[...]
> Having skimmed the referenced example (TaskScheduler.java):
> I assumed in my reply that it did something like "if (condition)
> wait();" where I would write "while (condition) wait();", but
> it doesn't. So a "never mind" may be in order. In the example,
> "notify" does seem okay given that -- if I'm understanding the code
> right -- only a single thread would ever be waiting?
As an aside, notify() can be the right choice even if more than one
thread is waiting (to avoid the thundering herd problem, for one thing).
The criterion is not whether only one thread is waiting, but rather,
whether more than one is needed to be awoken -- as long as all waits are
guarded by the same condition. In a worker thread setting, for example,
you normally only need one worker to service a newly queued request.
Waking up all others is not necessary. (There can be some fine points
regarding interrupt() in that case, but in most scenarios these do not
pose a real problem.) A solitary waiting thread is of course a special
case of that.
--
Cheers, Tilman
`Boy, life takes a long time to live...' -- Steven Wright
| |
| Tony Dahlman 2005-02-23, 4:00 am |
| blmblm@myrealbox.com wrote:
> In article <37qkqbF5gv31nU1@individual.net>, <blmblm@myrealbox.com> wrote:
>
>
>
> Having skimmed the referenced example (TaskScheduler.java):
> I assumed in my reply that it did something like "if (condition)
> wait();" where I would write "while (condition) wait();", but
> it doesn't. So a "never mind" may be in order. In the example,
> "notify" does seem okay given that -- if I'm understanding the code
> right -- only a single thread would ever be waiting?
>
Thanks for checking that and for your comments. The example code is as
simple as possible while still showing that "multiple" (i.e., 2) threads
can be waiting and both will start and run independently even though they
were waiting for the same condition.
http://pws.prserv.net/ad/programs/P...l#TaskScheduler
So, no, it is not an example of running the threads one at a time. But,
yes, everything is under complete control and 100% predictable, not to mention
repeatable.
And thanks for the heads up on that other thread where Tillman brings up
the issue of so-called spurious wakeups. I put in my 2 cents hoping for
some serious follow up. <gr>
--Tony Dahlman
--
---------------------------------------
nospam, I've had it, thanks.
| |
| blmblm@myrealbox.com 2005-02-23, 4:02 pm |
| In article <421C1D83.5080600@jps.net>, Tony Dahlman <adahlman@jps.net> wrote:
>blmblm@myrealbox.com wrote:
[ snip ]
[color=darkred]
>Thanks for checking that and for your comments. The example code is as
>simple as possible while still showing that "multiple" (i.e., 2) threads
>can be waiting and both will start and run independently even though they
>were waiting for the same condition.
Well .... As far as I can tell from your code, only one thread
at a time (the master/scheduler thread) is waiting in the sense
of having called wait() and not having been awakened by a notify()
or notifyAll(). You do have multiple threads waiting in the sense
of not having been started yet, but that's not really the same thing,
is it?
> http://pws.prserv.net/ad/programs/P...l#TaskScheduler
>
>So, no, it is not an example of running the threads one at a time. But,
>yes, everything is under complete control and 100% predictable, not to mention
>repeatable.
I don't think I said that only one thread at a time would run. I did
say that only one thread at a time would be waiting, in the sense of
having called wait(), etc.
>And thanks for the heads up on that other thread where Tillman brings up
>the issue of so-called spurious wakeups. I put in my 2 cents hoping for
>some serious follow up. <gr>
As did I! I was glad to get some info about this "spurious wakeups"
phenomenon. I'd been asking myself whether using the "put wait() in a
while loop" idiom was just sloppy thinking (can't be bothered to think
through whether the condition being waited for will remain true), so
it's nice to know that, no, there's a legit reason to use it anyway.
--
| B. L. Massingill
| ObDisclaimer: I don't speak for my employers; they return the favor.
|
|
|
|
|