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

Jeremy Manson jmanson at cs.purdue.edu
Thu Nov 10 14:15:45 EST 2005

Dawid Kurzyniec wrote:
> I am not sure how multiple statements could be make atomic without
> introducing mutual exclusion. But if you go there, the boundary
> between blocking and non-blocking statements becomes blurry... I feel
> a bit uneasy about that.

There are a lot of techniques in the works to do just this - it is a 
common research problem.  The idea is to import optimistic concurrency 
from databases.  The back end would take care of atomicity and 
visibility constraints, so the programmer could be free not to worry 
about that stuff.

I'm not sure why this would make you uneasy, though.  Databases employ 
this sort of concurrency all the time.  Wouldn't it be nice if everyone 
could write non-blocking data structures, instead of just people with 
Ph.D.s?  Also, if you can use atomic blocks instead of locking, many of 
the concerns of locking (deadlock, for example) become simplified 

> Also, the syntax for CAS is actually longer in this form than a.compareAndSet(). 

Yes, but it has the virtue of being comprehensible for those who don't 
know what a compareAndSet is, without extra work to go look it up.

I'm not claiming that such a structure would be a panacea, but I think 
it would be a lot nicer than special syntax for each method that could 
be invoked on an AtomicXXX.  I am also concerned that your syntax would 
discourage programmers from thinking about multi-variable invariants - 
i.e., it would make it TOO simple to have a single atomic action that 
doesn't relate to other associated actions correctly.  OTOH, an atomic 
{...} block might encourage programmers to group related actions that 
should be performed atomically.

> Perhaps the idea could be generalized to allow general constructs of
> the form foo.bar() { ... }, with before- and after- actions for bar()
>  defined by the class via annotations, and inserted by the source 
> compiler as needed. This would also in some sense generalize the 
> constructor invocation syntax for anonymous inner classes. Such a 
> general mechanism could benefit other APIs that rely on before/after
>  pattern. For instance, I can imagine a version of doPrivileged like
> this:
> AccessController.doPrivileged(acc) { // statements here; // can
> read/write local variables from enclosing block }

This is fairly close to what my annotation tool actually does.  More
specifically, you can define something that looks like this in a special

     public ReentrantLock rl = new ReentrantLock();

     void around() {
	try {
	} finally {

And you can define the following method:

@reentrant int f() {
   a.x = 1;
   return a.x;

And it will transform it (at the bytecode level) into this:

int f() {
   int returnVal;
   try {
     returnVal = realF();
   } finally {
   return returnVal;

int realF() {
   a.x = 1;
   return a.x;

You can adjust the around() method as desired to do pretty much whatever
you want it to do.  The problem is that you can't have it within a 
method scope (because you can't annotate individual statements).


More information about the Concurrency-interest mailing list