On Sat, Nov 13, 2010 at 01:11:01AM +0100, Johnny Billquist wrote:
>
> I just wanted a mutex and a lock interface which I could inline, and
> which only had the idea that I wanted to take or release a mutex or a
> lock. Some additional functions, like upgrading and downgrading rwlocks
> is also perfectly fine, as well as just trying to take locks, and to be
> able to query the lock/mutex for various information.
>
> For some reason, this wish is apparently an horrible idea to most people
> around here. For that I can only say that I'm sorry for you.
Among other things, that interface has to be designed so that it:
1) Is efficient and correct on multiprocessor systems with
considerably divergent memory and bus ordering constraints
and coherency models.
2) Does not needlessly smash cache lines and stall modern CPUs
waiting to access main memory.
Further, you also seem to be asking for less -- or no? -- use of atomic
CAS in the MI parts of the kernel, since VAX doesn't have it. But at that
point you're basically headed for a policy where you can't use lockless
concurrent algorithms at all -- fine on a uniprocessor like the VAX models
we support, where memory and the bus aren't so many cycles away anyhow; not
fine at all on most modern systems, whether MIPS, powerpc, ARM, x86, etc.
It's pretty clear, looking at the VAX architecture and many of the early
VAX models, that these kinds of issues were not really high on the agenda
for the original VAX architects, if they were on the agenda at all. Surely
people at IBM and elsewhere had explored them and various publications in
the mid/late 80's and 1990s (like the Synthesis papers) generally raised
awareness of them in the Unix community; but there's a _lot_ of old hardware
out there that really gets it wrong (R2000, anyone?) and almost no modern
hardware that does.
Most of the examples of how to do this or that with one VAX instruction
that have been raised in this thread have turned out to not actually work.
Matt did offer a rather wonderfully perverse way to do RAS...
> But as I said before. Implementing a mutex on a VAX, is really simple.
Sure. If you only care about slow uniprocessors, implementing a mutex
is simple.
> Just to be clear - I'm still not in any way saying that machines using
> CAS today should stop using it. What I was asking for was just a
> smoother way for machines that don't have CAS to have a way to implement
> the services used in other ways that would make more sense on those
> machines, while still providing the same end result.
Without CAS or an equivalent instruction, you pretty much can't do lockless
update to datastructures. I would not expect to see use of CAS disappear
from the NetBSD kernel, since on modern architectures one really wants to
do more things without taking locks whenever possible -- not less.
Given that, I can't see the benefit to removing one particular use of
atomic CAS in our kernel -- and I can see a great deal of reason _not_ to
prohibit MI code from creating more.
--
Thor Lancelot Simon t...@rek.tjls.com
"We cannot usually in social life pursue a single value or a single moral
aim, untroubled by the need to compromise with others." - H.L.A. Hart
