Re: Speaking of thread safety?

From:

Knute Johnson <nospam@rabbitbrush.frazmtn.com>

Newsgroups:

comp.lang.java.programmer

Date:

Sat, 13 Mar 2010 16:48:07 -0800

Message-ID:

<bnWmn.18302$ND2.7691@newsfe05.iad>

On 3/12/2010 12:34 AM, Peter Duniho wrote:

It's still very difficult to say for sure, because the SSCCE you posted
seems mostly about an alternate "observable" implementation that isn't
quite right, and attempts to provide guarantees that it's not actually
providing, while at the same time is contrived enough that it's not
really possible to see how your _real_ program is using threading.

If you _did_ have an Observable implementation (subclass) that did in
fact impose its own thread on the design (e.g. it has a worker thread
that's used to dispatch all the notifications), then any synchronization
issues that are raised for the _Observers_ in that scenario would need
to be dealt with by the Observers themselves. The Observable subclass
wouldn't have sufficient knowledge of the synchronization needed in
order to meet the needs of the Observers in any useful, practical way.

I hope that all of the above makes sense! :)

Pete

Pete:

Thanks very much for taking so much time to look at all of my code.
There were a lot of very good points in the code you sent me and I will
incorporate them. The one point that I'm not sure about is the call to
repaint() synchronizing data with the EDT. Looking at the code I don't
see how calling repaint() could create any synchronization. All that
happens is that some code is run on the EDT. No threads are started or
joined. I couldn't find anything in the docs that implied this either.

Thanks very much,

--

Knute Johnson
email s/nospam/knute2010/