Re: mutexes, locks and so on...

[Johnny Billquist <bqt%softjar.se@localhost>]

On 2010-11-13 00:48, Mindaugas Rasiukevicius wrote:
> 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.

Well, I might disagree with those reasonings, since I believe a better 
design would allow an implementation to be made on each machine that was 
optimal for that machine, while providing the same service.

If the issue is code duplication in the form of actually having similar 
code doing a CAS on a bunch of machines, that can be handled by a 
generic alternative, like we have in the mutex code today, which rely on 
just a few pieces being MD, such as how the CAS actually is implemented.

But why force that paradigm on everyone? I totally fail to see how that 
can be called a "better design".

> > 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?

Huh?
In which way do allowing the functions to be inline change any of that?
inline is just a way to allow the compiler to not wrap the functions in 
a function call, with all the implications that carry with it. It don't 
change things in any other way.

Well, maybe not totally true. It would mean that the intestines of the 
mutex had to be more exposed, since the code that manipulates them would 
be in the include file as well, to be able to inline it.
Today you can inline everything except mutex_enter and mutex_exit from 
mutex.h, which are the two functions you would most like to inline, 
since they are the ones being called in something close to the time 
crititcal code paths...

> So, what would be next?  #ifdef vax in sys/kern (since Ultrix had a bunch
> of these in its sys/sys)?

Yeah, right. Why don't we just delete sys/arch/{anything not vax}
Why do people insist on coming up with stupid replies?

        Johnny

--
Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email: bqt%softjar.se@localhost             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol