GC, the simple solution

[Sean Kelly]

Lionello Lunesu wrote:
> Sean Kelly wrote:
>> Lionello Lunesu wrote:
>>> ...that leaves only atomic operations? Or would "volatile" or 
>>> "synchronized" take care of memory fencing and such?
>>
>> "volatile" is actually intended to address compiler optimizations in a 
>> similar way to how memory barriers address CPU optimizations.  It is a 
>> necessary part of any lock-free operation in D.  "synchronized" is 
>> used for mutual exclusion and typically involves a mutex, so while it 
>> should have the proper effect, it's not lock-free.
> 
> So I suppose "volatile" could be extended to include memory locking as 
> well!

Yes it could, though for now I prefer it the way it is as it offers more 
control over exactly what's going on.  It helps tremendously that D has 
such good inline asm support.

> // instructions inside this block are 'lock'ed
> volatile(atomic) {
>     ++a;
>     a = x;
> }
> 
> (or perhaps even "synchronized(memory) {...}", but I think extending 
> volatile makes more sense).
> 
> Come to think of it, doesn't "synchronized" also imply "volatile"?

Yes.  Synchronization mechanisms rely on memory barriers to work 
properly.  In fact, it's been suggested in the past on c.p.t that an 
empty mutex block:

     synchronzed {}

could be used as a high-level sort of bidirectional memory barrier, 
except for the risk of the compiler optimizing the call away entirely.

> Or, another possibility would be to add the volatile declaration as in 
> C, but then actually locking all access to the variable:
> 
> volatile int i;
> i++;// atomic

This is sort of how Java implements volatile and it wouldn't surprise me 
if C++ did something similar.  Right now, the "volatile" qualifier 
offers basically no language guarantees for concurrent programming, as 
it was actually intended for accessing interrupt data IIRC.

> Seems to me it should be possibly to extend D with a built-in and 
> portable construct for these atomic operations.

Definately.  The trouble is coming up with a good design :-)  I think 
the C++ team is definately qualified to do so, but they may have to make 
some sacrifices in the interest of time.


Sean