Re: Atomic operations on the ARM

[Daniel Jacobowitz <drow at mvista dot com>]

On Mon, Jan 13, 2003 at 11:32:01AM +0000, Richard Earnshaw wrote:
> > 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.

Of course, switching to the generic mutex version does not really solve
the problem on Linux; since glibc contains the same incorrect
sequences.  I just haven't had time to test replacements, nor has
anyone else.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer