Re: Speaking of thread safety?
On 3/11/2010 2:20 PM, markspace wrote:
I don't know if you had time to read my earlier reply, but after I
posted it I starting thinking about the little design I posted. I'm
thinking that what I said--that it is probably good design to allow a
thread safe method of the observer--is just wrong.
There's two competing principles in design: 1. usefulness or ease of
use, and 2. pithiness. The opposite of pithiness is gold plating, a
If you over emphasize 1, then you risk a baroque, ornamented design that
takes 20 method calls to accomplish what should take just one method call.
If you over emphasize 2, then you risk a stark design that only works
for your particular need, but can't be extended and is difficult to
maintain due to it being too embedded in the particular code you wrote.
Always there's a balance to maintain.
Anyway, what I'm trying to say here is that because you have a JPanel to
begin with, you have events on the EDT anyway, so why not just skip the
thread safety and say all methods have to be called on the EDT?
Knute Johnson wrote:
Panel1 p1 = new Panel1();
Panel2 p2 = new Panel2();
This is EXACTLY the example I was going to provide, implemented on the
EDT just as you have. And it doesn't need to be specially thread safe,
it's naturally called on the EDT anyway.
Yes, making the classes not thread safe risks making the class hard to
use. But most Swing classes aren't thread safe, and folks are used to
dealing with that. So there's a well developed body of knowledge for
working with Swing classes that aren't thread safe, and I don't think
you're risking much by requiring the user be responsible for thread safety.
By contrast, especially after looking at your code, I think you are
risking a baroque, gold-plated, hard-to-maintain design by trying to
make the class totally thread safe. Events fire on the EDT because it's
fast to do so; trying to spawn a separate thread just to re-issue an
event to update your 2nd panel on the EDT again seems like mis-design.
(What one of my professors used to call "going around your elbow to get
from your forefinger to your thumb.")
Anyway, here's my design. I nixed your actual panel because it was just
easier to use a JTextArea for the example, but the whole thing fires on
the EDT, so it doesn't matter. It's all thread safe, and I don't have to
make any threads, and therefore things should happen quickly and the UI
should stay fast too. The code is shorter, and runs faster. Win-win.
(Note the JSpinner doesn't actually say that a ChangeListener is
guaranteed to be called on the EDT. I assume that it is. Therefore any
observer added can assume that it's update() method is also called on
the EDT, because of my design.)
Thanks for the code, the important parts were not that hard to read.
There are two issues that I was trying to solve using
Observable/Observer. First the docs for Observable say that the thread
calling Observer.update() may use a thread different from the one
calling Observable.notifyObservers(). "...but subclasses may change
this order, use no guaranteed order, deliver notifications on separate
threads..." So while Observable as it is currently written will deliver
notifications on the same thread as it was called from, that may or may
not be true later. If it isn't, the data may or may not be accessible
from another thread. Two, how to pass a message that was to be used in
multiple threads at the destination.
In my actual application that got me started down this path, I stored
the int in a volatile and everything is solved. The Observable could
use any thread, and the Observer could as well and my simple message is
fine. If I could be guaranteed that Observable would always call
notifyObservers() from the EDT and that I only wanted to use the data
from the EDT then there is no problem again. In my application I needed
to use the message data on the EDT and on another thread so I required
some sort of synchronization to guarantee that it would work.
If you are interested in the actual application, I have it running at:
Scroll to the bottom of the page and look at the VOR Trainer applet.
The source code is there as well.
So I still have one major question, how could one extend Observable and
modify notifyObservers() without access to the list of Observers? For
the example I had to re-create both Observable and Observer. Why would
Sun not have included a method to get the list of Observers?