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

Brian Goetz brian at quiotix.com
Thu Nov 10 23:57:24 EST 2005

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

I'm not sure that it needs to be right and fast for it to be damn useful 
today.  Getting locking right is just too hard for Joe Java. 
Concurrency bugs that make it into the field and fail there are very 
expensive.  So for Joe Java, something that gets it right, and not 
godawful slow, might still be a big improvement.  And it will get 
faster, just like everything else does (synchronization was pretty slow 
in Java 1.0.)

> 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 think the real win in the transactional stuff is that it makes writing 
a concurrent algorithm nearly as easy as writing a sequential one.  The 
performance of a V1.0 system might not be all that much worse than what 
Joe Java cooks up.

And with respect to annotations -- turn away from the dark side, Jeremy...

More information about the Concurrency-interest mailing list