[M3devel] firming up atomics?

[Tony Hosking]

I still have some fixes to check in before turning it on again.
They are intended to match the approved C++0x standard.

On 16 Oct 2010, at 20:27, Jay K wrote:

> 
> 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
>