| |||||||||||||
Short sleeps suffering from slackShort sleeps suffering from slackPosted Feb 25, 2012 21:08 UTC (Sat) by nevets (subscriber, #11875)In reply to: Short sleeps suffering from slack by cmccabe Parent article: Short sleeps suffering from slack
I mostly agree with you but there are a small set of legitimate uses of sched_yield(). The only real use case I can think of is a set of real time threads that are simulating its own voluntary scheduler.
If you have a set of threads all at the same priority, running FIFO and pinned to the same CPU, you can use sched_yield() to put yourself behind the other threads with the same priority and let them work. I've been on one project that did this.
The kernel stop_machine mechanism use to do this. It used yield() to let its other threads get the scheduler (all running highest FIFO priority). It did this method up till v2.6.26, after that, the algorithm was changed.
(Log in to post comments)
Short sleeps suffering from slack Posted Feb 26, 2012 22:48 UTC (Sun) by cmccabe (guest, #60281) [Link]
I'm not too familiar with SCHED_FIFO. But can't you use select(0, NULL, NULL, NULL, 0) to do the same thing? System calls are cancellation points, at least.
Incidentally, I was around for the cooperative multitasking days on Mac OS 6. It was not good. I'm sure there's some rationale for simulating that kind of thing in userspace, but a lot of times it smells like doing something in userspace that you ought to be doing in the kernel.
Short sleeps suffering from slack Posted Feb 27, 2012 12:21 UTC (Mon) by jengelh (subscriber, #33263) [Link]
select(timeout=0)? That's just as bad as sleep(0). sched_yield() looks a lot better, and since it is also a system call, there is your cancellation point.
|
|||||||||||||