[concurrency-interest] Concurrency Wrappers
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