Re: mutexes, locks and so on...

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

der Mouse <mouse%Rodents-Montreal.ORG@localhost> wrote:
> > 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 not.  It may be essential to your preferred implementation, but
> it is not essential to synchronization.  (Nor pretty much anything
> else, actually.  Not even if CAS is the operation you want for some
> reason; CAS can be implemented in terms of other primitives.)
> 
> The correct MI abstraction here is "sychronization".  (Or "atomic
> queue", or "mutext", or whatever.)  <...>

You might move theoretical boundaries that far and make a point, sure.
It is not practical, however.  What you seems to be offering here, is
to provide full "atomic queue", mutex(9), "whatever" interfaces in MD
land.  MD implementations result in code duplication, bugs, abstraction
problems, different behaviour problems and massive maintenance headache.
It is exactly the opposite way, we are successfully moving to (a lesson
we have realised in time).

While in old days, there was a belief that process grabbing from the
run-queue (together with context switch) in assembly would be faster,
(and in NetBSD 4.0 we still had MD cpu_switch() routine, it was a
horrible abstraction in today's standards.  As an example.

So yes, we do unify implementations/interfaces in MI (for many good
reasons, as noted) and therefore we do increase certain requirements
for MD land.  Do you really advocate to disperse everything back to MD?

> > If we do, then perhaps I picked the wrong project to join.. :)
> 
> One of us certainly did.

Apparently, we can agree on this. :)

-- 
Mindaugas