🚀 go-pugleaf

In article <19034@acorn.co.uk> mark@acorn.co.uk (Mark Taunton) writes:
>Clive Jones writes:
>>Hmm. I've just got my hands on a draft ANSI C standard, and it's quite
>>clear, unfortunately, that an implementation is under no obligation at
>>all to do this, however:
>>
>>It would be very nice if the compound assignment operators (+=, -=,
>>*=, etc.) were atomic if applied to volatile variables. The obvious
>>way to achieve this would be using SWP, 
>
>How?  Sorry to disappoint, but the SWP instruction (as its mnemonic
>suggests) implements the swapping of data between memory and
>registers, atomically (see below for details).  It doesn't implement
>atomic register-to-memory operations of any other sort.  Regretably,
>then, there is no obvious way to implement what Clive requests: the
>SWP instruction itself cannot be used to do it.  

Before posting, I came up with the following code, which updates the
variable pointed to by Ra, using v1 and v2 as scratch registers.

          LDR v1,[Ra]
loopback  MOV v2,v1
          < Perform the operation required on v1,
            eg. ADD v1,v1,#1  for  a+=1 >
          SWP v1,v1,[Ra]
          TEQ v1,v2
          BNE loopback

However, I have now checked the code, and, although it works fine for
two overlapping tasks, or for any number if the tasks are trying to
use equivalent operations, there is a potential for problems if three
tasks were to simultaneously try a|=1 a|=2 and a|=4, for example.

The problem arises because the above code updates the value in [Ra]
even if it has changed under its feet while it was processing. This is
unfortunate - what is really needed is is a TestAndReplace
instruction, similar to SWP, which means:

TAR Ra,Rb,[Rd] = 
  LOCK
  Load the old value from [Rd]
  TEQ that value with Rb, setting the ARM status flags on the result
  If Z is set, store Ra in [Rd]
  Put the old value of [Rd] in Rb
  UNLOCK

Unfortunately, this would require two transiently-held values at a time,
rather than one. )-8

My feeling is that there ought to be some modification to my above
code fragment that would make it secure in all cases - I'll think
about it. Can anyone else suggest a way to make it work for sure?

--Clive.