[M3devel] firming up atomics?

Jay K jay.krell at cornell.edu
Sun Oct 17 02:27:11 CEST 2010


Tony,

Can we firm up the atomic semantics/implementatino?

Now might be a good time for me to make the NT/x86 backend
definitely work, test it, and make it more efficient.
  (ie. not using InterlockedCompareExchange loop for InterlockedIncrement when a simple xadd will work).
 
 
Like, old value vs. new value returned?


Off the cuff, I'd say, better to always return old value.
The new value can always be computed from it.

However we are the mercy of the processors.


And it only matters for or/and.
xor/add/sub/inc/dec can all compute either from either.


Also, please, I don't find the specifications clear.
At least the last time I studied them.


To me they should say, things like,
 "returns the old value" 
 or "returns the new value" 

 
or returns true if compare matched
or returns false if the compare matched
etc.


The mentions of "spurious failure" or whatnot didn't make sense either.
They should say, something like:
returns true if the compare matched
 but sometimes even if the compare should have matched,
 it won't, and false will be returned -- specify everything that happens when there is "failure".

 
Furthermore, if you look at what Microsoft compilers provide,
they provide a bunch of very simple very clear well documented functions,
that the compiler implements and inlines.
 (at least if you ignore the qcuire/release stuff that confuses me...


You could specify in terms of them.
 Really. A good idea.


ie: is our compare_exchange equivalent to InterlockedCompareExchange?
  Or maybe parameter order different?

  
Of course, I understand, the types supported by the Microsoft
intrinsics have varied through time and slowly grown.
8bit and 16bit might still be lacking but 32bit and 64bit are very
complete. 64bit atomic operations on 32bit x86 processors 
since Pentium or so can be synthesized with a loop over
InterlockedCompareExchange64.


Or in terms of the gcc intrinsics, probably similarly ok.


We should probably also nail down the implementation where
they aren't available.


And maybe put in safer defaults?
  And quickly improve where we can, e.g. on all x86/AMD64 platforms.
  

 Thanks,
 - Jay
 		 	   		  


More information about the M3devel mailing list