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-06-28 (15:08) |
From: | Xavier Leroy <Xavier.Leroy@i...> |
Subject: | Re: [Caml-list] Thread and kernel 2.6 pb still there in CVS |
> I tried to submit a change in vouillon's entry in the bug tracking > system (classed as not a bug because can not reproduce), but as I am not > sure it worked, So I also post this here You should be grateful to Olivier Andrieu, who actually cared to submit a bug report along with useful info on 2.6 kernels. > In the latest CVS of ocaml there is still the periodic call Thread.yield > (through a sigalarm) in thread_posix.ml Yes, and that is necessary to get preemptive scheduling. Without this periodic Thread.yield, a thread that performs no I/O and no inter-thread communications would prevent all other Caml threads from running at all. > This implies that a threaded OCaml program ON A LINUX KERNEL 2.6 (at > least 2.6.3 on Mandrake 10, but probaby all 2.6) gets very little CPU > when another process is running (the usual figure is 10% CPU for the > threaded OCaml program against 90% for another program) Thread.yield does three things: - release the global Caml mutex, giving other Caml threads a chance to grab it and run; - call sched_yield() to suggest the kernel scheduler that now is a good time to schedule another thread; - re-acquire the global Caml mutex before returning to the caller. The 2.6 Linux kernels changed the behavior of sched_yield() in a way that causes the unfairness you observed. Other threaded applications are affected, including Open Office (!). My belief is that it's really a bug in 2.6 kernels and that the new behavior of sched_yield(), while technically conformant to the POSIX specs, lowers the quality of implementation quite a lot. (I seem to remember from my LinuxThreads development days that this isn't the first time the kernel developers broke sched_yield(), then realized their error.) The question I'm currently investigating is whether the call to sched_yield() can be omitted, as it's just a scheduling hint. Initial experiments suggested that this would hurt fairness (in Caml thread scheduling) quite a lot on all platforms other than Linux 2.6. More careful experiments that I'm currently conducting suggest that it might not be so bad. One can also play games where sched_yield() isn't called if there are no other Caml threads waiting for the global Caml mutex. In summary, a solution will eventually be found, but please be patient, and submit a bug report next time. - 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