Randall,
>Date: Fri, 25 Jan 2002 14:46:08 -0700
>From: "Simons, Randall W" <rsimons@xxxxxxxxxx>
>Organization: Sandia National Laboratories
>To: "'Steve Emmerson'" <steve@xxxxxxxxxxxxxxxx>,
>To: "Simons, Randall W" <rsimons@xxxxxxxxxx>
>Subject: RE: DisplayImpl Simplified: addReferences
The above message contained the following:
> Thanks for your reply. Here are some follow-on questions.
...
> Java in a Nutshell, 3rd Edition, p. 54 says: "If only one thread ever
> accesses a data structure, there is no need to protect it with
> synchronized."
The above assertion, while true, is akin to saying you can safely run
red lights if you know you're the only one on the road.
The following methods of DisplayImpl execute transactions on
RenderVector using "synchronized(mapslock)":
public void addReference(DataReference, ConstantMap[])
public void clearMaps()
public void addMap
public void doAction()
public void removeAllReferences()
void adaptedDisplayRemoveReference(DataReference)
void adaptedAddReferences(DataRenderer, DataReference[], RemoteDisplay,
ConstantMap[][])
private boolean computeInitialize()
public void addReference(DataReference, ConstantMap[])
private void addReferences(DataRenderer, DataReference[] refs,
ConstantMap[][], boolean)
If you can show that none of the above methods will be invoked while
the last method above is executing, then you can safely remove the
synchronization block in the last method. In general, this is probably
an NP-complete problem, so programmers rely on rules-of-thumb --
typically protecting invariants if there's the remotest chance of
their being corrupted.
The above is the most stringent condition -- you could remove the block
under less strict conditions that would, however, require even more
analysis.
> So I'm still curious about when and why multiple threads
> (using the same or other methods) might simultaneously modify a single
> instance of DisplayImpl.
Because some of the above methods are public, it is impossible to know,
a priori, if synchronization can be dispensed with.
> I'm hoping synchronization may not be necessary in
> certain well-defined circumstances.
Possibly, but I don't know what those circumstance might be. If they
can be delimited, then it might be possible to do something similar to
what the java.util package did with collections: implement
unsynchronized classes and a method to make them synchronized when the
user deems it necessary.
Delimiting those circumstances might be difficult and I'm afraid that I
don't have time to work on it.
Good luck.
Regards,
Steve Emmerson <http://www.unidata.ucar.edu>
