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

Jeremy Manson jmanson at cs.purdue.edu
Thu Nov 10 09:53:59 EST 2005


Dawid Kurzyniec wrote:
> Now, as the dust has settled and java.util.concurrent is a core library, 
> I am wondering if the next step should be to propose language extensions 
> to simplify usage of new tools, particularly locks and atomics? For 
> instance:
> 
> class A {
>  atomic int a;
>  final Lock lock = new ReentrantLock();
>  void foo() {
>    ++a; // -> incrementAndGet()
>    a ?= 5, 8; // ->compareAndSet(5, 8)
>    lock.lock() { // ->lock(); try { ... } finally { unlock(); }
>      // do stuff with the lock held
>    }
>  }
> }
> 
> Precedence for interface-based syntax support has been set by the 
> Iterable, and atomic is essentially a stronger incarnation of volatile. 
> So why not?
> 

Three things:

First, I don't think you would be able to convince the powers that be to 
introduce new syntax to support an API.  It tends to be something they 
don't like.  Generally, their feeling seems to be that APIs are the 
correct way to extend the language.  Which is why we get APIs that 
require rewrites of the entire system, like RTSJ and Isolates.

Of course, you can argue about the basic correctness of this view.  And 
you can argue about the presence of autoboxing and foreach loops.

Second, I, personally, would be more inclined to want to see a general 
purpose atomic block.  Something like this:

class A {
  int a;
  final Lock lock = new ReentrantLock();
  void foo() {
    atomic {
      ++a;
    }
    atomic {
      if (a == 5) {
        a = 8;
      }
    }
  }
}


Compilers could do the appropriate replacement, changing the first block 
to an increment and the second to something like a CAS.  The syntax 
could also be used to make multiple statements atomic, rather than being 
restricted to a single statement.  There is some momentum for such a 
creature in the academic community.

Third, having said this, it is possible to do some method-level stuff 
with annotations.  For example, I wrote a program that takes classes 
that look like this:

class Foo {

   @reentrant void a() {
      // does stuff
   }

}

and changes them to:

class Foo {

   ReentrantLock rl = new ReentrantLock();

   void a() {
     rl.lock();
     try {
       // does stuff
     } finally {
       rl.unlock();
     }
   }
}

which may suffice for new syntax for locking.  It just took a little bit 
of bytecode munging.

					Jeremy


More information about the Concurrency-interest mailing list