On Mon, 1 Oct 2007 15:17:52 -0700 "David Schwartz" <[EMAIL PROTECTED]> wrote:
> > Arjan van de Ven wrote: > > > > It can occasionally be an optimization. You may have a case where > > > you can do something very efficiently if a lock is not held, but > > > you cannot afford to wait for the lock to be released. So you > > > check the lock, if it's held, you yield and then check again. If > > > that fails, you do it the less optimal way (for example, > > > dispatching it to a thread that *can* afford to wait). > > > at this point it's "use a futex" instead; once you're doing system > > calls you might as well use the right one for what you're trying to > > achieve. > > There are two answers to this. One is that you sometimes are writing > POSIX code and Linux-specific optimizations don't change the fact > that you still need a portable implementation. > > The other answer is that futexes don't change anything in this case. > In fact, in the last time I hit this, the lock was a futex on Linux. > Nevertheless, that doesn't change the basic issue. The lock is > locked, you cannot afford to wait for it, but not getting the lock is > expensive. The solution is to yield and check the lock again. If it's > still held, you dispatch to another thread, but many times, yielding > can avoid that. yielding IS blocking. Just with indeterminate fuzzyness added to it.... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
