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: | -- (:) |
| 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