[concurrency-interest] Language extensions for java.util.concurrent?

Doug Lea dl at cs.oswego.edu
Fri Nov 11 09:29:54 EST 2005

This is getting increasingly removed from the usual concurrency-interest
topics, but ...

Jeremy Manson wrote:
>   Given that, the goal is (or should be) to create a set of 
> tools that are both comprehensible and usable in a broad range of contexts.

So, to provide transactional alternatives/complements to locking, you'd
want to support lightweight language-based constructions that mirror the
cases in which database-style transactions tend to work best:
   1. They contain well-defined read-sets and write-sets
   2. They do not contain side-effecting actions or IO
   3. They do not contain nested transactions (or only limited forms)
   4. They are short.

Databases normally ensure (1) and (2) "syntactically" (SQL etc).
They usually deal with (3) by either dynamically disallowing nesting or
by requiring additional setup/cost. And either don't deal with (4) at
all (with occasional crummy performance or lots of aborts etc) or
support special long-transaction constructions.

It's a challenge to come up with a combination of syntax and APIs
that captures this well. I do think that this is the right challenge to
undertake though, rather than for example allowing arbitrary "atomic {}"
blocks that just so  happen to be well-behaved when constrained in the
above ways that you can't enforce or even check.

> JSRs 133 and 166 do this well, but I would still argue that creating 
> (say) non-blocking data structures requires serious concurrency jujitsu. 

The main jujitsu is in inventing useful/efficient data-structures that
require only single-location compareAndSet. Until hardware can provide
multi-location transactional updates (coincidentally, in the same sense
as that above :-), and maybe even afterwards, these pointwise
solutions that take a lot of effort to devise and implement
correctly are likely to remain best choices.

But, in the same sense that you don't want application programmers to
bother re-implementing tricky non-concurrent data structures like
red-black trees, but instead use standardized APIs like TreeMap, I think
the most promising focus here is in identifying useful
concurrency-related APIs and providing the best implementations we can
come up with. Which just so happens to be the mission of JSR166 and its
follow-ons :-) And co-exists with longer-term goals like those above of
making  transactional forms more usable and useful for other kinds of


More information about the Concurrency-interest mailing list