NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Steve, 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
visad
archives: