Johnny Billquist <b...@softjar.se> wrote: > > Exactly! And I would like to emphasize that this has nothing to do with > > breaking of MI and MD abstraction or x86-centric view. 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 also essential for > > lock-free / wait-free algorithms, which are relevant both in SMP and > > real-time computing. > > But that is a decision I am questioning. When we talk about functions > such as mutexes and locks, why couldn't we have the API on the level > that is applicable to mutexes and locks? > Now we instead have an MI abstraction that assumes we have CAS, and > mutexes and locks are implemented in the MI code with the help of CAS. > <...>
Already wrote about reasoning in other reply to mouse (keywords: no code duplication, better design), so wont repeat myself. > While in there, I would of course also advocate that these functions be > possible to write as inline functions, which they cannot be today, and > that would benefit everyone. But I guess some people might not be > interested in such a gain? What do you want to inline? Functions of mutex(9) interface? And break clean KPI, stable ABI of mutex(9) and all kernel modules using it? So, what would be next? #ifdef vax in sys/kern (since Ultrix had a bunch of these in its sys/sys)? -- Mindaugas
