[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: mutexes, locks and so on...
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)?
Main Index |
Thread Index |