> 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 mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
