Re: Why is Observerable.setChanged() synchronized
Mike Schilling wrote:
"Thomas Weidenfeller" <nobody@ericsson.invalid> wrote in message
news:eice4e$pep$1@news.al.sw.ericsson.se...
tomerbd1@gmail.com wrote:
I'm looking at java.util.Observable code and I noticed that
setChanged() is synchronized, however i can't figure out why... anyone
can help me?
protected synchronized void setChanged() {
changed = true;
}
A couple of remarks, non of which might apply:
(b) One can see such things in several of the original Java 1.0 classes,
e.g. the pre-collection classes like Hashtable. My guess is that the
original Java designers were a little bit naive when it came to
multithreading and synchronization.
Or, more likely, they understood it quite well
Understood the mechanism, but were naive about the practice.
If you want a change to the state of an object to be visible in all threads,
you need to synchronize both the code that makes the change and the code
that checks for the change. Observable does this correctly:
Which I think is Thomas Weidenfeller's point (a).
Say we were actually proposing to use this effort in a thread-safe
class. The fields of our subclass will also need to be guarded, and so
it rather makes sense to call setChanged under out lock (probably the
same one) anyway.
Ignoring mixing the subclass and Observable class locking for a moment,
to modify stuff, we'll have code like:
synchronized (this) {
++this.x;
}
setChanged();
notifyObservers("x");
Suppose we had another piece of code with x replaced by y. The might be
called at the same time. There should be two observations: one with "x"
and one with "y". But both threads may call setChanged first, then it
becomes a race to notify.
So: Threading can be difficult. Events can be difficult. Mixing
threading and events is challenging. See Swing for an example cock up.
Tom Hawtin