CODEWITHSUNDEEP
cmultithreadinglinux-kernelposixscheduling
Hugo Haldi
Hugo Haldi

Reputation: 51

sched_yield() system call and real time scheduling policies

I was wondering how to use the scheduling mechanisms in Linux kernel with multiple threads, and I saw that sched_yield() system call can send the current thread to the end of the process queue. Since SCHED_OTHER is the default scheduler policy, the manual doesn't recommend to use this system call while using SCHED_OTHER because it is intended to be used with real time scheduling policies (man 2 sched_yield) and is unspecified with SCHED_OTHER:

sched_yield() is intended for use with real-time scheduling policies (i.e., SCHED_FIFO or SCHED_RR). Use of sched_yield() with nondeterministic scheduling policies such as SCHED_OTHER is unspecified and very likely means your application design is broken.

However, I saw this page from the RedHat documentation saying that sched_yield() shouldn't be used with real time tasks:

The sched_yield system call is used by a thread allowing other threads a chance to run. Often when sched_yield is used, the thread can go to the end of the run queues, taking a long time to be scheduled again, or it can be rescheduled straight away, creating a busy loop on the CPU. The scheduler is better able to determine when and if there are actually other threads wanting to run. Avoid using sched_yield on any RT task.

So how do I should use the sched_yield() system call ? What this would do with a SCHED_OTHER or a SCHED_FIFO policy ? From what I understood is that with a SCHED_FIFO policy, the thread won't be interrupted unless a sched_yield(), and then the second requested thread will be processed unless it end, and the first thread will continue when all the thread queue has been processed (with a FIFO behavior).

Also, what this system call would do with the SCHED_RR policy, since all the threads are partially processed each quantum ?

Upvotes: 4

Views: 1499

Answers (1)

Maxim Egorushkin
Maxim Egorushkin

Reputation: 136256

Linus Torvalds' comment about sched_yield:

The problem with that is "yield" is pretty much undefined. The definition of it is literally about single queue of a real-time behavior with a real-time scheduler with priorities.

But that "definition" has almost nothing to do with actual usage. There are various random people who use it, and some might use it for locking, while some use it for other things.

...

sched_yield() is basically historical garbage. It's often literally wrong even for the defined usage because times have moved on from that whole "we run one thing at a time" long long ago. If your RT system actually has multiple concurrent threads (as opposed to being limited to a dedicated CPU) it's not really all that well-defined even there. But at least there you can still pretend it is.

Upvotes: 2

Related Questions