Right.
What happens is that it's basically a user-mode spinlock that on
contention does a kernel ioctl.
The spinlock is in a shared memory data structure, that the kernel driver
also knows about etc, and yes it needs kernel support for the final
product, but you can do a lot of testing in user-mode alone (make it
thread-safe within one process first, and THEN look at how to make it safe
between processes through a shared area).
> Oh. And btw. It's already been done. See the 3dfx driver.
>
> This was the premise of most of this thread I thought. "3dfx do it
> the lock way" and here is some other way we're discussion the merits
> of for hardware that has the capability.
Note that historically atomic locks have been EXPENSIVE. I think that was
true on MIPS too, even with the load-locked thing, just because with the
weak cache coherency the thing was initially done on the _bus_, not inside
the CPU. But happily that time is long gone, and it's not coming back.
(The early alpha implementation of LD_L + ST_C was entierly uncached, and
just took a hundred cycles or more to generate a SMP-safe lock. Ugh.
Double-ugh. Intel does it in 20 cycles or so, and I think even that is
excessive, but they probably have good synchronization reasons for it).
So it may be that at one point people _really_ didn't want to do the
explicit lock. I think that time is past.
Note that the 3dfx driver works, but who knows, it can certainly have
bugs. But I did not get a bad feeling about including the DRM code from
Precision Insight into the kernel - unlike this "playing with mappings"
thing that just makes me shiver.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/