[M3devel] m3back atomic current summary

[Tony Hosking]

Jay, I don't understand your issues here.

On 12 Feb 2010, at 09:20, Jay K wrote:

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

Which new value?  There is no *requirement* that CompareSwap return the actual value in the register:

     The CompareSwap operation may fail spuriously, that is return false while
     leaving the value in "expected" unchanged.  A consequence of spurious
     failure is that nearly all uses of CompareSwap will be in a loop:


> The new value doesn't come back in a register
> and rereading memory will not be atomic.

Again, I don't understand this.

>  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/2dc78cd5/attachment-0002.html>