caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
* 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;
as well as URLs for NNTP newsgroup(s).