[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: mutexes, locks and so on...
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
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
(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 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
Main Index |
Thread Index |