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
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 (18:18)
From: Goswin von Brederlow <goswin-v-b@w...>
Subject: Re: [Caml-list] Threads Scheduling
Philippe Wang <philippe.wang.lists@gmail.com> writes:

> On Tue, Apr 13, 2010 at 11:56 PM, Gregory Malecha <gmalecha@gmail.com> 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 <daniel.buenzli@erratique.ch>
>> wrote:
>>> You may also be interested in this thread [1].
>>> Daniel
>>> [1]
>>> http://groups.google.com/group/fa.caml/browse_thread/thread/9606b618dab79fb5
>> --
>> gregory malecha
> Hi,
> 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.

Meaning: Ocaml uses cooperative multithreading, not preemptive.