English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
[Caml-list] Why must types be always defined at the top level?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ 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