[concurrency-interest] Concurrency Wrappers
Wed, 25 Jun 2003 20:27:35 -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 5:51 PM
Subject: Re: [concurrency-interest] Concurrency Wrappers
> > I think this feature is a quick hack, incoherent with the
> > thoughtful design of the rest of the API.
> I prefer the term orthogonal.
Orthogonality is a property of two unrelated traits of a system. Using a
example from this API would be executor and locks, each is independent from
the other, but they can be combined in a single system. When I said
incoherent I was was comparing "a quick hack" vs. "thoughtful design", both
are qualifiers for the same trait: design. Beauty isn't orthogonal to
uglyness, and adding a scar to a otherwise beautiful painting is incoherent.
> > 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.
> In my experience, many concurrency issues can be
> handled through whole object synchronization strategies.
> The existing wrappers in java.util.Collections go a long
> way towards solving concurrency problems when you use
> collections heavily. When they are inadequate, other
> measures need to be taken.
Whole object synchronization strategies can cause deadlocks when you
don't expect, because unsuspect methods will be synchronized together.
There's always situations where this strategy works, but most objects aren't
simple and they usually collaborate with several other objects.
> > 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.
> I guess that depends on what kind of program you
> are writing. Perhaps most Java programs should be
> designed around concurrency. My guess is that most
> programmer deal with concurrency only after it
> causes problems.
That's the problem with such "helper" classes. They can introduce subtle
bugs very easily. It's against the Java "let's play safe" philosophy. I know
that there are other ways to create bugs (e.g. forgetting to unlock a lock)
but they're harder to produce, because they're harder to use.
> Just for a point of reference, my background as
> a Java applications programmer is in writing stand-alone
> desktop Swing apps and database driven JSP/Servlet apps.
> I freely admit to being outclassed by the gurus on this
> list, but that probably makes me a more typical user.
> > IMHO these kind of helper methods can lead to
> > lot's of difficult to track deadlock bugs.
> Lots of testing helps discover deadlocks.
> I've found the thread dump a relatively easy way
> of pinpointing deadlocks.
I agree that deadocks caused by monitor-based synchronization are
somewhat easy to find, but when we're using the Lock interface there's no
info on the thread dump. Also most kinds of deadlocks occurs once in a
while, because they require a particular set of conditions.
As a side note I've used this kind of strategies some times to make
quick hacks and midnight patches, but ASAP I changed them to real working
designs. The Java library must be coherent and stable, so people would be
able to trust any given API. One of the most annoying bugs in the Bug Parade
is related to Date class being thread-unsafe, because of a quick hack to
cache the timezone (IIRC).
"There's no such thing as a tough child -- if you parboil them first for
seven hours, they always come out tender."
- W.C. Fields
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