On Fri, 30 May 2003, Denis Oliver Kropp wrote:
In the kernel part of Fusion (our IPC API) I'm currently calling yield() after unlocking a "long-time" lock. Maybe you have some hints before I'm working on that issue.
You really shouldn't unconditionally yield. That just tells the kernel that you don't have anything to do, and since it isn't "directed" any way the kernel can't really do anything smart about it, and has to assume that you're less important than basically _all_ other programs (modulo nice levels).
Which looks like it works for many trivial cases, and gives _wonderful_ interactivity, but you'll see just how much it sucks if you ever have a compile going on in the background, and you continually yield to it and tell the system that the compile is more important than you are. See the problem?
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...
------------------------------------------------------- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
