On Mon, 1 Oct 2007 15:44:09 -0700 "David Schwartz" <[EMAIL PROTECTED]> wrote:
> > > yielding IS blocking. Just with indeterminate fuzzyness added to > > it.... > > Yielding is sort of blocking, but the difference is that yielding > will not idle the CPU while blocking might. not really; SOMEONE will make progress, the one holding the lock. Granted, he can be on some other cpu, but at that point all yielding gets you is a bunch of cache bounces. >Yielding is sometimes > preferable to blocking in a case where the thread knows it can make > forward progress even if it doesn't get the resource. (As in the > examples I explained.) that's also what trylock is for... as well as spinaphores... (you can argue that futexes should be more intelligent and do spinaphore stuff etc... and I can buy that, lets improve them in the kernel by any means. But userspace yield() isn't the answer. A yield_to() would have been a ton better (which would return immediately if the thing you want to yield to is running already somethere), a blind "yield" isn't, since it doesn't say what you want to yield to. Note: The answer to "what to yield to" isn't "everything that might want to run"; we tried that way back when the 2.6.early scheduler was designed and that turns out to not be what people calling yield expected.. (it made their things even slower than they thought). So they want "yield to" semantics, without telling the kernel what they want to yield to, and complain if the kernel second-guesses wrongly.... not a good api. - 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/
