Thanks for your reply. Here are some follow-on questions.
> -----Original Message-----
> From: Steve Emmerson [mailto:steve@xxxxxxxxxxxxxxxx]
> Sent: Friday, January 25, 2002 12:54 PM
> Because the RendererVector field that was protected by the above
> synchronization block is also accessed by other methods as
> part of their
> transactions, removal of the synchronization block runs the risk of
> corrupting the invarients of the class.
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." 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. I'm hoping synchronization may not be necessary in
certain well-defined circumstances. For example, if I'm not using VisAD's
distributed computing features, and I'm not doing any multi-threading in my
application, is this synchronization unnecessary?
> > What are the situations where mapslock could be accessed by
> more than one
> > thread? Is synchronization only necessary when doing
> distributed computing
> with RMI? If so, could we have an option in VisAD to turn
> off support for
> > distributed computing when we don't need it? Such an
> option might be useful
> > elsewhere as well.
> All VisAD Display-s have their own threads.
Are these the only threads that access the DisplayImpl objects? How many
are there for each Display? Is there somewhere I should look in the
documentation or code to learn more about the thread structure of VisAD?
Randall W. Simons
Sandia National Laboratories