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

Jeremy Manson jmanson at cs.purdue.edu
Thu Nov 10 19:44:40 EST 2005

David Holmes wrote:
> 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.

I'll go even farther and say that I don't think there will ever be a 
one-size-fits-all solution for concurrency and synchronization, any more 
than there is a one-size-fits-all solution for, say, control flow.  We 
have if statements and do-while loops and while loops and for loops - 
there is no reason that there can't be a range of flavors for 
concurrency.  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.

JSRs 133 and 166 do this well, but I would still argue that creating 
(say) non-blocking data structures requires serious concurrency jujitsu. 
  Learning and understanding the correct use of volatile and AtomicXXXX 
is hard!  I think that this is the area that development of atomic 
should focus on.  And given the number of non-blocking algorithm 
implementations that require at least some restart / retry, I think it 
is reasonable to have that be part of it.

> 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! ;-)       :-)

I'm so ashamed!  I should go back to my original idea, which was to use 
Aspect Oriented Programming!  It is so much simpler and easier to 
understand!  And the resulting code is so much easier to read!

"Annotation Tool", "Pre-processor", "Po-tay-to", "Po-tah-to".  Call it a 
pre-processor if it makes you feel better.  The annotation isn't 
changing the code's behavior, the bytecode rewriter is.  It just happens 
to be using the annotation as a marker to decide when to do it.


More information about the Concurrency-interest mailing list