Knute Johnson wrote:
On 3/10/2010 8:48 PM, Peter Duniho wrote:
If the mutable Object was thread-safe, then it would handle that.
Otherwise, you'd have to use some mechanism for ensuring
synchronization. As far as I know, Java doesn't have an explicit memory
barrier API, so "synchronized" is probably the best approach for simple
mutation observability issues.
Pete
And there's the rub. If you have as in my case, two separate classes,
where you don't want to share data other than that which is shared via
the Observable/Observer, how do you get the Observable instance in the
Observer to then use to synchronize with? You have to assume that a
different thread could read the data after it was stored via the
Observer.update() method.
Without a code example, it's hard for me to know for sure what you're
talking about. However, if you are asking how to get the reference to
the Observable instance so that you can use that reference in a
"synchronized" statement, then the answer is "you don't, nor should you".
Unless you specifically want to write some special thread-safe
Observable sub-class that handles this, the synchronization isn't
something the Observable needs to know about at all, nor would it be
anything that needs the Observable instance itself. The synchronization
is between the threads modifying the data and reading the data, while
the Observable is just a by-stander.
If you can provide a SSCCE that illustrates the relationship between
your Observable, an Observer, and whatever other code exits that is
modifying a mutable class instance, as well as examining that mutable
class instance in a different thread, then surely a solution can be
described that provides the necessary synchronization, but without
necessarily making the Observable a central figure in that.
Note that, depending on how strict you want to be about this whole
"don't want to share data other than that which is shared via the
Observable/Observer", you may require a wrapper class to impose the
synchronization needed.
But with an Observable that is not itself imposing a multi-threaded
implementation, it's not at all clear how you managed to get two classes
that know nothing of each other except for the Observable, and yet which
are going to access the same data on two different threads. Either each
class is associated with its own thread, and one knows about the other,
or only one class includes code executing on two different threads (e.g.
an Observer in one thread, and some other stuff in another), in which
case it only needs to synchronize within itself.
Basically, until it's clear how it is you've got an Observable that
involves itself in cross-thread communication, in which two different
threads involve two completely mutually-isolated classes except for an
Observable mediating, and yet in which the Observable itself isn't
involved in the threading, it's very hard to suggest a design that will
work for you.
After all, since the default Observable implementation simply calls
update() in the same thread where notifyObservers() was called, how is
it that the writer thread is different from the reader thread in the
first place?
I suspect that once you've focused on the answer to that question,
you'll see the division between the two threads where the
synchronization has to take place, and it probably will be simple to
implement that synchronization independently of the Observable behavior.
If you post a SSCCE, I'm sure you'll get good advice, if not from me
then from someone else. :)
Pete
Good points and I think I have figured out how to do this. I have to go