Ian Romanick wrote:
Linus Torvalds wrote:
You _really_ want to use futex'es for any user-space locking. It's back-ported to 2.4.x, and it gets these cases _right_. There are fair user-space locks based on futexes as part of modern glibc sources, and they are _fast_, since all non-contention (common case) is done entirely in user space, and they do the right thing (*) when there is contention.
You're right. We do _really_ want to use futex'es. However, I don't think they're available on *BSD or Solaris. I don't know if there's anyone working on DRI right now that knows enough about Linux and *BSD to be able to determine what the effort would be to make futex'es or a futex-like wrapper for those systems. I honestly believe that is the only reason we haven't already started using futex'es.
We also have the problem of having to support old kernels with new user-mode drivers.
Hmmm...I'll have to look in to futex'es more...
As promised, I have finally looked into the mystical futex. The short version is that it should be dead simple to convert the existing DRI drivers to use either the existing locking method or a futex. And now for the rest of the story...
A futex is actually very similar to the existing DRI lock. This is the main thing that will make transitioning the to futex interface so simple. Basically, a futex is just a variable in shared memory. When a thread wants to acquire the futex it decrements the variable. If it's non-negative, the thread happily continues on. If the value is negative, the thread calls into the kernel to block. At this point, the futex is virtually identical to the existing DRI lock.
The real difference comes at the unlock. When a thread wants to release the futex, it increments the variable. If the value is greater than zero, the thread happily continues on. If the value is zero or negative, the thread calls into the kernel to wake-up the next waiting thread. It is this last part that differentiates the futex from the existing DRI lock. It is also this last part that gives the behavior we were trying to achieve by calling sched_yield after releasing the DRI lock.
I don't think you can get the same behaviour as the DRI lock from just a futex alone. Specifically, the DRI lock makes it easy to notice when you weren't the last locking context, eg:
Context A locks
Context A unlocks
Context A locks
****Here both Futex & DRI lock say "OK, nothing to do, context A gets the lock"
Context A unlocks
Context B locks
****At this point, a native futex would say "ok, B gets the lock, no problems, nothing to do", wheras the DRI lock would say "Agh! different context grabbing the lock, gotta do some extra work", specifically set the hardware up the way B expects it to be.
Now, in the original DRI design, it was concieved that the kernel would do a lot of that extra work to virtualize the hardware, while actually we end up doing it all in userspace.
I guess all this means is that we need a 'last context' variable in addition to the futex, to detect this situation. But that does mean that we have to alter (slightly) the sarea layouts, right?
Keith
------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
