[concurrency-interest] Concurrency Wrappers
Wed, 25 Jun 2003 15:44:40 -0300
----- Original Message -----
From: "Curt at Tripos" <firstname.lastname@example.org>
To: "Curt at Tripos" <email@example.com>;
<firstname.lastname@example.org>; "Daniel Yokomiso"
Sent: Wednesday, June 25, 2003 2:45 PM
Subject: Re: [concurrency-interest] Concurrency Wrappers
> > As it is very easy to do something similar
> > using dynamic proxies (i.e.
> > regarding a known set of interfaces), I don't
> > think it should be part of
> > this library.
> 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.
> 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.
> > 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.
There are some easy to implement features that won't be part of this
JSR. If you read the past threads you'll see the reasoning for this. I think
this feature is a quick hack, incoherent with the thoughtful design of the
rest of the API. Most classes in real world projects can't be made
concurrent through simplistic whole object synchronization strategies,
because synchronization is related to sets of methods, not them all. You
could create several interfaces, each representing a set of synchronizable
methods, and create combinations of proxy handlers to deal with different
synchronization strategies (e.g. in a BoundedBuffer create a general
Reader-Writer lock to deal with commands/queries, but use a wait/notify lock
to deal with empty/full signals), but this is requires quite a bunch lines
of code, not "without changing a single line of code". Sometimes we need
some quick hacks to debug a system or put out a prototype, but concurrency
is a complex issue that can't be dealt with some kind of patching.
IMHO these kind of helper methods can lead to lot's of difficult to
track deadlock bugs. It would be very difficult to find a class with only
methods of mutually-exclusive access. There's always some method that could
be accessed by more than one thread at a time without harm, but when you
make it an all or nothing synchronization strategy you'll harm everyone who
makes this simples assumption.
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.491 / Virus Database: 290 - Release Date: 18/6/2003