Browse thread
[Caml-list] Why must types be always defined at the top level?
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2004-07-05 (16:34) |
From: | Xavier Leroy <Xavier.Leroy@i...> |
Subject: | Re: [Caml-list] Thread and kernel 2.6 pb still there in CVS |
> 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