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

David Holmes dholmes at dltech.com.au
Thu Nov 10 18:55:33 EST 2005


My 2c :-)

Dawid writes:
>   atomic int a;
>     ++a; // -> incrementAndGet()
>     a ?= 5, 8; // ->compareAndSet(5, 8)

Hmm this smacks of operator overloading! :) I don't think this sort of
syntactic shorthand buys you that much, and the messier part is the details
of passing 'a' as an argument or returning 'a' from a method. Personally I
like to see what the code actually does - eg. a.compareAndSet(...) and be
able to see just by looking at a code fragment that 'a' is not a plain old
int. I do like the ?= operator though :)

As for the more general form that Jeremy is discussing:
  atomic { ... }

I just don't buy into this sort of system magic (yet!). Languages have been
trying to sell the "tell us what you want and we'll figure out how to do it"
story on concurrency for many many years. They don't succeed because
basically noone believes they can both do it right and fast. There is no
one-size-fits-all solution for concurrency and synchronization, and until
there is people want control over how these things are done. Maybe we are
edging closer to that but I don't think we are that close yet.

The software transaction stuff is promising for some things (like replacing
synchronized with an optimistic approach that falls back to locking) but the
issue of restarts and side-effects still indicate to me that they are not a
general solution to the problem. They work well in databases but that is an
environment where there are no side-effects other than the actions of the
transaction on the database.

>     lock.lock() { // ->lock(); try { ... } finally { unlock(); }

This is a job for IDE tools, like eclipse (which I think does something like
this). Though if continuations were ever to be added to the language then
something like:
    lock.lock() { ... } -> lock.withLock(new Runnable { ... })
might be reasonable.

Aside: there have been some informal proposals for general before/after
"try" blocks over the years but they never gained enough general support to
be considered worthwhile. As Dawid alluded, exceptions and return values
make things messy.


As for Jeremy's annotation tool ... Egads man! That's not an annotation tool
it is a pre-processor! Shame on you for subverting annotations in that way.
Anyone who has read the JLS should know that annotations are not meant to
affect semantics! ;-)       :-)

Cheers,
David Holmes



More information about the Concurrency-interest mailing list