From: Linus T. <tor...@tr...> - 2003-05-29 23:23:09
|
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. |