tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: mutexes, locks and so on...

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

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 Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email:             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

Home | Main Index | Thread Index | Old Index