i'm not really assuming anything, i gave a vague first impression of the
vague example you gave (assuming that the yield was done to combat
fairness problems). This is a case where the human language shows its
boundaries: statements that are hard to refute with certainty because
they are too vague. So i'd really suggest you show me some sample/real
code - that would move this discussion to a much more productive level.
but i'll attempt to weave the chain of argument one step forward (in the
hope of not distorting your point in any way): _if_ the sched_yield()
call in that memory allocator is done because it uses a locking
primitive that is unfair (hence the memory pool lock can be starved),
then the "guaranteed large latency" is caused by "guaranteed
unfairness". The solution is not to insert a random latency (via a
sched_yield() call) that also has a side-effect of fairness to other
tasks, because this random latency introduces guaranteed unfairness for
this particular task. The correct solution IMO is to make the locking
primitive more fair _without_ random delays, and there are a number of
good techniques for that. (they mostly center around the use of futexes)
one thing that is often missed is that most of the cost of a yield() is
in the system call and the context-switch - quite similar to the futex
slowpath. So there's _no_ reason to not use a futexes on Linux. (yes,
there might be historic/compatibility or ease-of-porting arguments but
those do not really impact the fundamental argument of whether something
is technically right or not.)
Ingo
-
