Messages in this thread | | | From | Kyle Moffett <> | Subject | Re: yield API | Date | Wed, 12 Dec 2007 23:43:51 -0500 |
| |
On Dec 12, 2007, at 17:39:15, Jesper Juhl wrote: > On 02/10/2007, Ingo Molnar <mingo@elte.hu> 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
| |