Re: mutexes, locks and so on...

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

Johnny Billquist <bqt%softjar.se@localhost> 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