Re: Atomic operations on the ARM

[Richard Earnshaw <rearnsha at arm dot com>]

> Hi Richard,
> 
> Did You encounter real program failure due to the discussed issue with 
> atomicity.h on ARM ? Or this is purely logical conclusion that it's unsafe ?
> 
> I'm asking this question , becouse mentioned code is only vulnerable to 
> the double user process scheduling out in the period of one (!) 
> instruction execution time ( between swp and cmp instructions and 
> between cmp and swpne instructions ).
> 
> This looks impossible for me at least on Linux and uniprocessor. Am i 
> wrong ?
> 
> Regards, Vladimir.

Well SWP didn't exist on ARM2 (so you have to handle it by trapping into 
the kernel and simulating the instruction), but that's a minor issue now.  
More significant issues with the code were:

1) The theoretical uni-processor problem.
2) The code won't work at all on a multi-processor system, since the SWP 
locations would have to be placed in NCNB memory.
3) The Thumb implementation was completely broken (it failed to jump back 
into Thumb state after completing the ARM code sequence -- so we ended up 
executing Thumb instructions in ARM state).  I think this is a GAS bug, 
but the code was so horrible anyway that there seemed to be little to be 
gained from trying to fix it.
4) ARMv6 defines new load-locked/store-conditional instructions which are 
much better suited to this problem.  There's a serious question as to 
whether these functions should be inlined or provided in a 
machine-specific library (say in libgcc.a) so that the correct and most 
suitable sequence is executed on the processor.

All in all, there seemed to be a lot of potential problems with the code 
and some real ones, so there seemed to be little point in pretending that 
it did what it claimed to do.

There were several alternatives discussed on the mailing list which would 
be much more viable.

R.