> Atomicity of the purge/replace op itself?  
> 
> or.... If Mach mapped these onto Mach message exchanges, and then
> replacing all current restartable-atomic-ops with a known, single op
> (exec()-like?)  was dynamically common, then I could see it making
> sense.

It doesn't make sense from an atomicity standpoint..

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.

It may make sense from an efficiency/"reduced number of syscalls"
standpoint, but I would think that exec would do an implicit PURGE_ALL
(since the new address space has nothing to do with the old), and
you'd register your one or two atomic sequences early in the life of
the new address space, most likely before any other threads were
spawned, and at the very latest

One other comment.. any PURGE operation should be considered to have
undefined behavior if there are any other runnable threads in the
address space which might be executing within the registered atomic
sequence(s) at the time of the PURGE.  The caller of PURGE must be
responsible for ensuring that there is some form of coordination with
other threads to prevent Bad Things from happening..

					- Bill