[jdom-interest] Re: static data needs to be thread data for multithreaded applications
jozart at csi.com
Fri Sep 22 20:30:59 PDT 2000
The subject seems to suggest that the solution would be (1) to use
ThreadLocal data for namespaces and other data that is currently static.
ThreadLocal is a Java2 feature. Using thread local has these
disadvantages: you can end up duplicating the cached data and the work
involved in creating it in each thread.
Other options appear to be: (2) synchronizing access to the static data
or (3) doing-away with the static data.
If (2) is the solution, my advice is to limit the critical section to
the smallest size possible, and then show that performance *is* a
problem before trying to do anything more clever.
As Bill Pugh says: "Using synchronization isn't that expensive, and it
serves as important and useful documentation to programmers about the
intended thread interactions in your code."
At a glance, I don't see how the critical section around namespaces can
be easily reduced... As I pointed out before, most optimizations
designed to reduce synchronization in Java are just plain wrong,
including double-check locking:
Option (3) has some nice properties, though - like compatibility with
garbage collection. Can the data that is static now be moved into a
factory as instance data?
More information about the jdom-interest