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?
For example, if you asked me whether pipes are the best thing for
certain apps, i could immediately show you tons of examples where they
are. Same for sockets. Or RT priorities. Or nice levels. Or futexes. Or
just about any other core kernel concept or API. Your notion that
showing a good example of an API would be "difficult" because it's hard
to determine "smart" use is not tenable i believe and does not
adequately refute my pretty plain-meaning "it does not exist" assertion.
If then this is one more supporting proof for the fundamental weakness
of the sched_yield() API. Rarely are we able to so universally condemn
an API: real-life is usually more varied and even for theoretically
poorly defined APIs _some_ sort of legitimate use does grow up.
APIs that are not in any real, meaningful use, despite a decade of
presence are not really interesting to me personally. (especially in
this case where we know exactly _why_ the API is used so rarely.) Sure
we'll continue to support it in the best possible way, with the usual
kernel maintainance policy: without hurting other, more commonly used
APIs. That was the principle we followed in previous schedulers too. And
if anyone has a patch to make sched_yield() better than it is today, i'm
of course interested in it.
Ingo
-
