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

Jeremy Manson jmanson at cs.purdue.edu
Fri Nov 11 11:02:55 EST 2005


Doug Lea wrote:
> This is getting increasingly removed from the usual concurrency-interest
> topics, but ...

It's concurrent, isn't it? ;)

> 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.
> 
> 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.

My point was that atomic blocks are only one tool in the concurrent 
programmer's toolbox, not that atomic blocks are applicable in every 
context.  Sorry if that was unclear from the message.  It bothers me 
when people try to sell atomic blocks as a panacea.

As far as the specific challenges - well, as I said in my first message, 
I elided lots of detail.  I agree that these are several of the obvious 
challenges / limitations when developing effective atomic sections for a 
programming language.

Chris Purcell took issue with 3, which he says are usually supported:

 >   3. They do not contain nested transactions (or only limited forms)

If there are going to be atomics in use in libraries, it becomes pretty 
important to support nested ones.   From my point of view, support for 
nested transactions depends on what you expect them to do.  Their 
semantics can get arbitrarily hairy.  IMO, it is better to keep them 
simple where they occur (by making them reentrant, for example, in the 
same way as synchronized blocks).

We could exchange messages for months on all four points, though, so it 
might be better not to get too deeply into this.


>> 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.

I agree with this; it was, effectively, my point.  Structuring 
algorithms around this is extremely tricky, as you know.

> 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.

It may, in fact, take hardware support before atomic sections are useful 
to a broad audience.  As for afterwards - well, if you have it, it makes 
sense to be able to use it.

However, I think it is possible to use atomic sections in the meantime 
for platforms for which you have well-understood constraints that make 
it possible to implement them.  Cooperative systems / user-level thread 
systems make implementation of atomic blocks a bit easier and more 
sensible, for obvious reasons.  But then we are straying away from pure 
Java...

> 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
> usages.

I wouldn't disagree.  Obviously, your first line of resort should be to 
see if there is an existing library that will fill your needs.  JSR-166 
provides an excellent array of tools.

It is very easy to get carried away with shoving concurrency extensions 
into the language.  I can think of several languages that suffer from 
this problem.  There is a tendency to shoehorn in every feature that the 
designer thinks is cool.  But I would say that in this case that there 
is a hole in what the language provides (which is the ability to do 
multi-location transactional updates).

					Jeremy


More information about the Concurrency-interest mailing list