Re: wait and spurious wakeups
apm35@student.open.ac.uk wrote:
On 27 Nov, 23:18, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
[...]
Summary: Always use
synchronized(thing) {
while (! readyToGo())
thing.wait();
doLockedThings(thing);
}
doOtherThings(thing);
... because it will always be safe, no matter what happens.
I will do this. But there is still something I don't quite understand.
If the readyToGo() method is also synchronized on 'thing' (which it is
in my case) then I dont need to call readyToGo, do I? I could access
the private member directly. Another thread cannot access the variable
because I am already synchronized via the line "synchronized(thing)",
right?
The details of readyToGo() will depend on the application
at hand. Sometimes it might be a simple expression involving
a couple of member variables in `thing'. Sometimes it might
be a method call like isEmpty(). The decision to proceed or
to wait depends (presumably) on the state of `thing', and (also
presumably) there are other threads that modify that state and
will call notify() or notifyAll() when they do so.
The reason for synchronizing before making the test is to
prevent weird things from happening if the other threads make
changes while readyToGo() is in the middle of making up its
mind. That's also the reason for performing doLockedThings()
while synchronized: If you didn't, the changes you make could
confuse the other threads.
The `synchronized' block doesn't make any tests, as such,
and doesn't guarantee anything about the state of its object.
All it does is give your thread exclusive access, in the sense
that no other thread can synchronize on that same object until
your block completes. That means (if you've programmed things
properly) that no other thread will change the object's state
while you're examining it, and that any changes you make while
inside the block will appear to all the other threads as if
they happened simultaneously.
Of course, it's possible to make misteaks. If some thread
examines or alters `thing' in "open code" without `synchronized',
the fact that your thread synchronizes on it is no help. This
is one area where object-oriented programming makes it easier
to avoid accidental race conditions: If you make all the state
private to the object's class and use accessor and mutator
methods to get at it, you can put all the synchronization inside
the class. Then instead of writing in the Javadoc "Please be
sure to synchronize before doing X," you can just provide a
method that does X and always synchronizes, making it impossible
for the caller to forget to do so. Even this is not a complete
cure-all, but it's a big help.
--
Eric Sosman
esosman@ieee-dot-org.invalid