[concurrency-interest] Language extensionsforjava.util.concurrent?

Dawid Kurzyniec dawidk at mathcs.emory.edu
Thu Nov 10 15:37:14 EST 2005


Jeremy Manson wrote:

> Dawid Kurzyniec wrote:
>
>> 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?
>
>
> There are several ways of ensuring this, most of which just take some 
> imagination; the "right" one probably depends on what you need from 
> your system.  Here's some brief discussion, which is by no means 
> complete.
>
> First, you might say that "atomic" only means atomic if a given 
> variable is always accessed in an atomic section.  Otherwise, the 
> multivariable invariants don't hold.  So, for example, a thread which 
> accesses b and a outside an atomic block might see b == 4, but a == 
> something else.  This may seem bad, but it is roughly analogous to 
> writing code with data races in it.
>
> That would ensure that atomic blocks only need to be atomic with 
> respect to each other.  And this is a significantly easier problem.
>
> One simple solution: record all writes in an atomic block to a log, 
> instead of writing them directly to memory.  At the end of the block, 
> if the memory that has been accessed has not changed, then briefly 
> block (in the same sense that all machine level atomic actions briefly 
> block) and perform all updates atomically.  If the memory has been 
> changed, then restart.


Jeremy, thanks for the info and references I find it very interesting.

Restarting would require that all invoked methods are idempotent, but I 
think that invoking a method from an atomic block borders with abuse anyway.

Abuse of atomic blocks would cause livelocks, just like abuse of 
synchronized blocks causes deadlocks. Interesting.

Regards,
Dawid



More information about the Concurrency-interest mailing list