Re: mutexes, locks and so on...

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> Exactly!  And I would like to emphasize that this has nothing to do
> with breaking of MI and MD abstraction or x86-centric view.

Yes, I imagine you would.  But it's still false.

> Decision was to provide CAS abstraction [sic!] as a primitive for MI,
> by the MD land - in a same way, like we have copy(9), fetch(9),
> store(9) or many other means, just in this case MI asks MD to ensure
> atomicity.  It was relevant to make a break-through for better SMP
> support, since it is an essential primitive used for synchronisation.

It is not.  It may be essential to your preferred implementation, but
it is not essential to synchronization.  (Nor pretty much anything
else, actually.  Not even if CAS is the operation you want for some
reason; CAS can be implemented in terms of other primitives.)

The correct MI abstraction here is "sychronization".  (Or "atomic
queue", or "mutext", or whatever.)  CAS, if used, should be a part of
the implementation.  It may even be shared among MD implementations for
which it is appropriate.  But to impose it on arches which don't have
it but which do have perfectly good synchronziation (or whatever)
primitives is to draw the MI/MD break at the wrong place, to push MD
aspects into supposedly-MI code, just as much as building code based on
INSQTI/REMQHI and then requiring everything not supporting atomic DLL
ops to implement those somehow would be.

> What Johnny apparently suggests is to revisit mutex(9) interface,
> which is known to work very well, and optimise it for VAX.  Well, I
> hope we do not design MI code to be focused on VAX.

Why not?  You don't mind designing it in (other) MD ways.

> If we do, then perhaps I picked the wrong project to join.. :)

One of us certainly did.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B