Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Threads Scheduling
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2010-04-14 (08:40)
From: Philippe Wang <>
Subject: Re: [Caml-list] Threads Scheduling
On Tue, Apr 13, 2010 at 11:56 PM, Gregory Malecha <> wrote:
> Hi Jake,
> The documentation for Condition.wait says:
> wait c m atomically unlocks the mutex m and suspends the calling process on
> the condition variable c. The process will restart after the condition
> variable c has been signalled. The mutex m is locked again before wait
> returns.
> I figured that I needed to lock and unlock the mutex in the child threads
> because otherwise it is possible for the condition variable to be signaled
> before the main thread waits, which I thought means that the signal is
> lost.
> Thanks Daniel, I'll take a look at it.
> On Tue, Apr 13, 2010 at 5:04 PM, Daniel Bünzli <>
> wrote:
>> You may also be interested in this thread [1].
>> Daniel
>> [1]
> --
> gregory malecha


Your f function *might* prevent preemption...
For instance, if
let f () = while true do () done;;
then it means f does not allocate nor call any external function, and
so it the scheduler is stuck because scheduling is done at allocation
or *some* external functions (which contain "blocking sections", e.g.,
I/O operations).
So it is important that when using Thread module, there is, for
scheduling, at some point a call to an allocation or a "blocking"
operation, or Thread.yield.
As most functional code will allocate, this problem is not so frequent, though.

Philippe Wang