On Dec 12, 2007, at 17:39:15, Jesper Juhl wrote:
On 02/10/2007, Ingo Molnar <[email protected]> wrote:
sched_yield() has been around for a decade (about three times
longer than futexes were around), so if it's useful, it sure
should have grown some 'crown jewel' app that uses it and shows
off its advantages, compared to other locking approaches, right?
I have one example of sched_yield() use in a real app.
Unfortunately it's proprietary so I can't show you the source, but
I can tell you how it's used.
The case is this: Process A forks process B. Process B does some
work that takes aproximately between 50 and 1000ms to complete
(varies), then it creates a file and continues to do other work.
Process A needs to wait for the file B creates before it can
continue. Process A *could* immediately go into some kind of "check
for file; sleep n ms" loop, but instead it starts off by calling
sched_yield() to give process B a chance to run and hopefully get
to the point where it has created the file before process A is
again scheduled and starts to look for it - after the single sched
yield call, process A does indeed go into a "check for file; sleep
250ms;" loop, but most of the time the initial sched_yield() call
actually results in the file being present without having to loop
like that.
That is a *terrible* disgusting way to use yield. Better options:
(1) inotify/dnotify
(2) create a "foo.lock" file and put the mutex in that
(3) just start with the check-file-and-sleep loop.
Now is this the best way to handle this situation? No. Does it
work better than just doing the wait loop from the start? Yes.
It works better than doing the wait-loop from the start? What
evidence do you provide to support this assertion? Specifically, in
the first case you tell the kernel "I'm waiting for something but I
don't know what it is or how long it will take"; while in the second
case you tell the kernel "I'm waiting for something that will take
exactly X milliseconds, even though I don't know what it is. If you
really want something similar to the old behavior then just replace
the "sched_yield()" call with a proper sleep for the estimated time
it will take the program to create the file.
Is this a good way to use sched_yield()? Maybe, maybe not. But it
*is* an actual use of the API in a real app.
We weren't looking for "actual uses", especially not in binary-only
apps. What we are looking for is optimal uses of sched_yield(); ones
where that is the best alternative. This... certainly isn't.
Cheers,
Kyle Moffett
--
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
