[concurrency-interest] Concurrency Wrappers
Curt at Tripos
Curt at Tripos <firstname.lastname@example.org>
Wed, 25 Jun 03 15:51:33 -0500
> I think this feature is a quick hack, incoherent with the
> thoughtful design of the rest of the API.
I prefer the term orthogonal.
> 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.
> 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
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.