> Just a last question:
> Now I saw that for "non broken" sched_yield, the call is still present.
> Are you sure that releasing the mutex is not enough to tell the 
> scheduler it may be a good time to give some cpu to another caml thread 
> blocked on the same mutex ?

In general, when there's code in the Caml implementation, it's for a
good reason.

> But I am sure you tested that too and this is why the call is still 
> there when possible ;-)

Yes, I tested.  Spent more than one day setting up and refining a test
harness, then running it on a variety of Linux and non-Linux systems.
Had to install a Fedora Core 2 somewhere to assess the damage done in
kernel 2.6.  In the meantime, read a bunch of condescending mailing
list posts along the lines of "if you're using sched_yield(), you must
be doing busy-waiting and that's wrong".  (Guess what?  I'm not doing
busy waiting!)  The conclusions are clear: sched_yield() does improve
fairness and has no significant costs in the situation corresponding to
Caml threads (contention on a master lock); and the Linux 2.6
developers managed to make sched_yield() useless for this purpose.

If the above sounds mildly irritated, that's because I am.

- Xavier Leroy

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners