Re: mutexes, locks and so on...

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

On 2010-11-12 17:58, Mindaugas Rasiukevicius wrote:
> 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.

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.

Hadn't it been much nicer of we just had the mutex and lock abstraction, 
and left the whole implementation to each MD part? Possibly with a 
fallback implementation in MI code, using CAS if you really didn't want 
to implement mutexes and locks, and were happy with either having CAS, 
or else just implement a CAS?

As it is now, there is no choice. You have to implement CAS, and a lot 
of work is going to be done through CAS, even if you'd like to implement 
something "better"?

Like I said from the start, the mutex part is actually almost there. The 
rwlock code however, is totally away from that.
And mutex could use a little tweaking to make it better, there are still 
some parts of the mutex code that always require a CAS implementation to 
exist.
(And I'm sortof not happy with the global variables held for mutexes, 
which is ugly, but that is another issue).

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

It do, when the operations we actually talk about are locks and mutexes. 
They can be implemented equally effective on all of these architectures, 
but we have chosen to limit ourself by deciding that the MI code will 
use an architecture specific feature, namely CAS, when I believe it 
should not have needed to do that.

It's an absurd MI abstraction to zoom in on a specific architecture 
feature for a concept that itself have no need for such a feature.
A lock or a mutex does not, in any way, depend on CAS as a concept, 
anywhere. CAS is just one way of implementing such a thing. There are 
others. I thought the whole point of doing something in a MI way was to 
avoid such a design.

> 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.. :)

I certainly am not advocating an optimization for the VAX. I'm 
advocating an MI design that leaves MD implementation open to do it 
whatever way is optimal for that architecture. That way, people who like 
CAS, and use machines that have CAS can continue to use CAS, while me on 
the VAX could implement something else, that would make more sense on a VAX.
It would not hurt anyone else, but could possibly benefit a bunch of ports.

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?

        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