Browse thread
Threads Scheduling
[
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: | 2010-04-14 (08:40) |
From: | Philippe Wang <philippe.wang.lists@g...> |
Subject: | Re: [Caml-list] Threads Scheduling |
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. -- Philippe Wang mail@philippewang.info