This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Atomic operations on the ARM
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Vladimir Serov <vserov at infratel dot com>
- Cc: Richard Earnshaw <Richard dot Earnshaw at arm dot com>, Daniel Jacobowitz <drow at mvista dot com>, gcc-patches at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org
- Date: Mon, 13 Jan 2003 11:32:01 +0000
- Subject: Re: Atomic operations on the ARM
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw 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.