> > Atomic.cmp_exchange( i, i, dest ); // can be used as atomic read or
write.
>
>
> Why not just do that as a library function? That's what I've done before, writing it in inline assembler.

Hmm. It's a puzzle, this one.

By nature I am firmly in the Stroustrup camp, i.e. I prefer libraries to language features. The same instinct informs on what I hope to see in the breakdown between D itself, the D runtime library and external libraries.

However, in this case I am strongly of the contrary opinion. To be honest, I don't know that I can form a cogent argument at this time. I may have to get back to you on that.

I will say that I've been spending a lot of time thinking about atomicity in the languages, and C/C++'s pretty useless volatile keyword. I *strongly* want this to be provided more inately by the language in D.

Matthew Wilson wrote:
>>>Atomic.cmp_exchange( i, i, dest ); // can be used as atomic read or write.
> 
>>Why not just do that as a library function? That's what I've done before,
>>writing it in inline assembler.
> 
> Hmm. It's a puzzle, this one.
> 
> By nature I am firmly in the Stroustrup camp, i.e. I prefer libraries to
> language features. The same instinct informs on what I hope to see in the
> breakdown between D itself, the D runtime library and external libraries.
> 
> However, in this case I am strongly of the contrary opinion. To be honest, I
> don't know that I can form a cogent argument at this time. I may have to get
> back to you on that.
> 
> I will say that I've been spending a lot of time thinking about atomicity in
> the languages, and C/C++'s pretty useless volatile keyword. I *strongly*
> want this to be provided more inately by the language in D.
> 

my belief that atomic op's should be in the language and not within a library is their use.
the main time I've used atomic ops was on append only lists where speed was important to avoid the need for a mutex (or similar).

I don't mind if the syntax makes it look like a library call (so it can be implemented as a library on an arch that does not have the primatives) but it should be reduced in the object code to the smallest/fastest possible code that the platform allows.

if implemented within the compiler then on x86 "lock smashing" can be performed by the D runtime lib etc.
i.e. atomic read/write would generate
`lea edx, <some-address>; xchg eax, [edx];`
however if it is running on a uni processor the implicit `lock` causes a cache flush etc, but is not actually required so can be replaced with
`mov eax, <some-address>; nop` or `mov <some-address>, eax; nop`
before the code is run.