I've met Brian Bershad a couple of times, and I'd guess there's *some*
reasonable justification. I don't see a compelling reason, myself, but
it's been a long time.


>The only reason why you'd need something like this to be atomic was if
>there could be a race between multiple threads in the address space.
>But if there's a race, then the other thread might conceivably be *IN*
>one of the "old" (about-to-be-purged) atomic sequences and could have
>the rug pulled from underneath it by being preempted at a bad spot.

My recollection is that RAS does't work for SMP locking: it's
uniprocessor-only. RAS in a nutshell is :

   *if* you got an interrupt in a critical region, and therefore *may*
   have interleaved execution of the critical region with
   some other thread, *then* wind the interrupted thread back to
   the start of its RAS  critical region before resuming, just in case.

If you have 2 or more CPUs, then threads on two more CPU can happily
proceed through the same RAS-protected section, without incurring any
interupt or context switch. RAS permits this, therefore it doesn't
provide mutual exclusion on SMP hardware.

Other solutions are needed for SMP boxes.  IIRC, the paper RAS cites
software-only approaches like Dekker's algorithm or Peterson's
algorithm, for a known max number of CPUs, using pre-allocated,
per-CPU slots. I would prefer not to remember what I once knew about
SGI's polutions for r3k SMP boxes (hardware-enforced mutexes,
sychronization busses, all that ugly stuff).