Re: mutexes, locks and so on...

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

Antti Kantee <pooka%cs.hut.fi@localhost> wrote:
> On Fri Nov 12 2010 at 14:30:58 +0100, Johnny Billquist wrote:
> > By reasoning that we should design for tomorrows hardware, we might as 
> > well design explicitly for x86_64, and let all other emulate that. But 
> > in the past, I believe NetBSD have tried to raise above such simple and 
> > naÃve implementation designs and actually try to grab the meaning of
> > the operation instead of an explicit implementation. That have belonged
> > more in the field of Linux. I hope we don't go down that path...
> 
> Freeway design is not driven by the requirements of the horse.  If a horse
> occasionally wants to gallop down a freeway, we're happy to let it as long
> as it doesn't cause any impediment to the actual users of the freeway.
> 
> Over 15 years ago NetBSD had a possibility to take everyone into account
> since everyone was more or less on the same line.  This is no longer true.
> If old architectures can continue to be supported, awesome, but they may
> in no way dictate MI design decisions which hold back the capabilities
> of modern day architectures.

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.

The fact is that pretty much all modern architectures have CAS or LL/SC
at hardware level, and can deliver a "fast" CAS mean.  This can make VAX,
sparc or mips1 users a little bit upset, because these will have to
provide the functionality using workaround ways, which give performance
penalty.  However, all this does not break MI and MD abstraction.

What Johnny apparently suggests is to revisit mutex(9) interface, which
is known to work very well, and optimise it for VAX.  Well, I hope we
do not design MI code to be focused on VAX.  If we do, then perhaps I
picked the wrong project to join.. :)

-- 
Mindaugas