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.
> BTW, you might want to look at Fusion when you have time (see our web cvs).
Docs/design where?
Linus
(*) Right thing: sleep and _directed_ wake-ups, no random yields.
-------------------------------------------------------
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
