[concurrency-interest] Concurrency Wrappers

Dawid Kurzyniec dawidk@mathcs.emory.edu
Wed, 25 Jun 2003 14:22:42 -0400

> I assert that "easy to implement" isn't a
> strong enough argument to keep functionality out of
> a utility.  java.lang.ThreadLocal is one example.
> If it is generally useful, then there is
> no sense in a large percentage of users writing their
> own implementations, or finding someone elses.
> In my experience, these would be generally useful.


I agree that such wrappers would be useful in simple cases, but I think they 
could as well be dangerous in more complex ones. Too much synchronization 
(e.g. blindly making all methods synchronized like in this case) can easily 
lead to liveness problems, not to mention performance degradation. See the 
Doug Lea's book for in-depth discussion of the matter. Presence of such 
wrappers in the library would create false impression that the proper way 
from thread-unsafe to thread-safe is by making all methods synchronized. This 
is the practice that many inexperienced programmers already are falling for, 
and I fell it should be discouraged rather than further encouraged.

> Also, I didn't mean to limit the wrappers to just
> those two.  They should be included, however, since
> they are the simplest and most generically useful.
> I would also argue for the inclusion of methods to
> construct wrappers that apply different concurrency
> mechanisms to different methods.

I think that concurrency control is so application-specific that it is simply 
impossible to embrace all (or even most) cases inside a single library. And 
even if it was, there would be many classes with a lot of configuration 
options, and I think that they would not save people much work as compared to 
the alternative of implementing their custom wrappers.

> > Otherwise it's very difficult to
> > know how to implement such
> > methods using plain Java, because if you don't
> > know the exact interfaces,
> > you can't easily (i.e. without heavy reflection
> > usage + byte-code
> > generation) define the appropriate proxies. In
> > the collections case the
> > interfaces are known at compile-time, so it isn't
> > a problem.
> If factory methods for wrappers are put in place now,
> any users will get a speed bump (without changing a single
> line of code), if and when the
> reflection + byte-code-generation route is implemented.
> Witness the evolution of ThreadLocal's implementation.

Considering the fact that the appropriate wrappers are very easy to write (and 
that it can be automated by a simple script if that's what you need), you are 
essentially requesting very heavy-weight mechanisms  (which would bloat the 
class libraries and require a lot of time to implement by people who could 
otherwise work on something more useful) to provide rather minor 
simplification for end-users. For that reasons, I would personally opt 
against it.