* Threads Scheduling @ 2010-04-13 20:33 Gregory Malecha 2010-04-13 20:54 ` [Caml-list] " Jake Donham 2010-04-13 21:04 ` Daniel Bünzli 0 siblings, 2 replies; 6+ messages in thread From: Gregory Malecha @ 2010-04-13 20:33 UTC (permalink / raw) To: caml-list [-- Attachment #1: Type: text/plain, Size: 1295 bytes --] Hello, I'm trying to write a function (run_guarded) that takes another function (f), and runs it for some amount of time. If f terminates with value x, then the result of run_guarded should be Some x, otherwise it should be None. Here's my implementation using the Thread library: let run_guarded f x = let res = ref None in let m = Mutex.create () in let c = Condition.create () in let _ = Mutex.lock m in let tid1 = Thread.create (fun x -> let z = f x in let _ = res := Some z in let _ = Mutex.lock m in let _ = Mutex.unlock m in let _ = Condition.broadcast c in ()) x and tid2 = Thread.create (fun () -> let _ = Thread.delay 0.3 in let _ = Mutex.lock m in let _ = Mutex.unlock m in let _ = Condition.broadcast c in ()) () in let _ = Condition.wait c m in let _ = Mutex.unlock m in let _ = try Thread.kill tid2 with _ -> () in let _ = try Thread.kill tid1 with _ -> () in !res It seems like it should work, but it doesn't work if the function f doesn't terminate. It seems to be running everything serially. I know that threads aren't actually parallel, but I thought they were preemptive in which case it seems like this should work. Does anyone know what I did wrong here? Thank you very much. -- gregory malecha [-- Attachment #2: Type: text/html, Size: 1780 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Caml-list] Threads Scheduling 2010-04-13 20:33 Threads Scheduling Gregory Malecha @ 2010-04-13 20:54 ` Jake Donham 2010-04-13 21:04 ` Daniel Bünzli 1 sibling, 0 replies; 6+ messages in thread From: Jake Donham @ 2010-04-13 20:54 UTC (permalink / raw) To: gmalecha; +Cc: caml-list On Tue, Apr 13, 2010 at 1:33 PM, Gregory Malecha <gmalecha@eecs.harvard.edu> wrote: > It seems like it should work, but it doesn't work if the function f doesn't > terminate. It seems to be running everything serially. I know that threads > aren't actually parallel, but I thought they were preemptive in which case > it seems like this should work. Does anyone know what I did wrong here? You have a deadlock---the main thread has the mutex locked and won't unlock it until the condition is signaled; neither of the other threads will signal the condition until the mutex is unlocked. There is no reason to lock/unlock the mutex in the two child threads. Jake "crossing fingers" ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Caml-list] Threads Scheduling 2010-04-13 20:33 Threads Scheduling Gregory Malecha 2010-04-13 20:54 ` [Caml-list] " Jake Donham @ 2010-04-13 21:04 ` Daniel Bünzli 2010-04-13 21:56 ` Gregory Malecha 1 sibling, 1 reply; 6+ messages in thread From: Daniel Bünzli @ 2010-04-13 21:04 UTC (permalink / raw) To: gmalecha; +Cc: caml-list You may also be interested in this thread [1]. Daniel [1] http://groups.google.com/group/fa.caml/browse_thread/thread/9606b618dab79fb5 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Caml-list] Threads Scheduling 2010-04-13 21:04 ` Daniel Bünzli @ 2010-04-13 21:56 ` Gregory Malecha 2010-04-14 8:40 ` Philippe Wang 0 siblings, 1 reply; 6+ messages in thread From: Gregory Malecha @ 2010-04-13 21:56 UTC (permalink / raw) To: Daniel Bünzli; +Cc: caml-list [-- Attachment #1: Type: text/plain, Size: 1154 bytes --] 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 > > _______________________________________________ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > -- gregory malecha [-- Attachment #2: Type: text/html, Size: 2025 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Caml-list] Threads Scheduling 2010-04-13 21:56 ` Gregory Malecha @ 2010-04-14 8:40 ` Philippe Wang 2010-04-14 18:18 ` Goswin von Brederlow 0 siblings, 1 reply; 6+ messages in thread From: Philippe Wang @ 2010-04-14 8:40 UTC (permalink / raw) To: Gregory Malecha; +Cc: Caml List 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Caml-list] Threads Scheduling 2010-04-14 8:40 ` Philippe Wang @ 2010-04-14 18:18 ` Goswin von Brederlow 0 siblings, 0 replies; 6+ messages in thread From: Goswin von Brederlow @ 2010-04-14 18:18 UTC (permalink / raw) To: Philippe Wang; +Cc: Gregory Malecha, Caml List 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. MfG Goswin ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-04-14 18:18 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-04-13 20:33 Threads Scheduling Gregory Malecha 2010-04-13 20:54 ` [Caml-list] " Jake Donham 2010-04-13 21:04 ` Daniel Bünzli 2010-04-13 21:56 ` Gregory Malecha 2010-04-14 8:40 ` Philippe Wang 2010-04-14 18:18 ` Goswin von Brederlow
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox