GC, the simple solution

Lionello Lunesu lio at lunesu.remove.com
Fri Jun 16 02:55:27 PDT 2006


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!

// 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"?

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

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

> It would be nice, but I've yet to see a proposal that I like.  The 
> problem is that in addition to pure atomic operations (which is how the 
> x86 typically works by default) lock-free programmers typically want to 
> make an assertion about instruction ordering as well, and built-in 
> semantics don't expose this very cleanly.  One could simply have 
> volatile types similar to Java where no optimization is allowed on them 
> at all, but this may be too heavy-handed to satisfy some folks.  For 
> now, I think a library solution is a reasonable alternative.  Ares has 
> had one for quite a while and it's almost standalone so it could be used 
> with Phobos with very little effort.  The documentation is here (DDoc 
> seems to want to generate docs for private template functions, so I 
> apologize for the clutter):
> 
> http://svn.dsource.org/projects/ares/trunk/doc/ares/std/atomic.html
> 
> And the code itself is here:
> 
> http://svn.dsource.org/projects/ares/trunk/src/ares/std/atomic.d


Thanks, I'll have a look at them.

L.



More information about the Digitalmars-d mailing list