[concurrency-interest] Language extensions forjava.util.concurrent?

Dawid Kurzyniec dawidk at mathcs.emory.edu
Thu Nov 10 14:59:27 EST 2005

Jeremy Manson wrote:

> 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 substantially.
The "uneasiness" was because I thought that locks would be silently 
inserted to handle more complex atomic blocks. If atomic {} is always 
non-blocking, then I may buy into the idea. But optimistic concurrency 
algorithms must deal with failures and retries. How would that look 
like? And what does the following mean:

atomic {
   if (a == 6) { foo(); b=4; a=5; } else a = 4;

Would the compiler have to ensure that a is not changed by other threads 
after it is read in the atomic block? But how to do that without 
blocking that other threads?

More information about the Concurrency-interest mailing list