[M3devel] m3back atomic current summary

Jay K jay.krell at cornell.edu
Fri Feb 12 15:20:39 CET 2010


"m3back atomics summary"


After a while of looking at this, I conclude
that the atomics interface has a bunch
of functionality that doesn't map all that
well to what x86 provides, and vice versa.

 


In particular x86 allows

 lock mem or reg
 lock mem xor reg
 lock mem and reg
 lock not mem
 lock neg mem
 and several others

 


but the requirement of the atomic interface
to return the new value makes these not line up.
The new value doesn't come back in a register
and rereading memory will not be atomic.

 


Now I see why the C compiler's _InterlockedOr and such
use _InterlockedCompareExchange in a small loop.


 

Any xchg with a memory operand on x86 is always atomic.

 

 

fetch_and_op for add/sub can probably be more efficient using xadd.

You get back the old value but you can do the add a second time.

 

 

I understand the point isn't necessarily to expose whatever x86 can do,

but also to provide an interface that can be reasonably implemented

across various hardware (mips, alpha, powerpc, sparc, arm, hppa, ia64, maybe 68k).

 

 

It's possible the front end (or backend) should notice if the return value

is ignored, such as by preceding it with EVAL, and then those can be

implemented more efficiently.

The NT386 backend does not have the level of sophistication required to do that.

 

 

I'm torn on even providing this stuff.

It's all very tricky to use.

However any "systems" language should probobably

provide for a portable efficient lock package, that

others can then easily use.

 


 - Jay

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100212/68d9263c/attachment-0001.html>


More information about the M3devel mailing list