From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 783A87EE4B for ; Fri, 27 Sep 2013 12:51:13 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of bgrundmann@janestreet.com) identity=pra; client-ip=38.105.200.229; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="bgrundmann@janestreet.com"; x-sender="bgrundmann@janestreet.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of bgrundmann@janestreet.com designates 38.105.200.229 as permitted sender) identity=mailfrom; client-ip=38.105.200.229; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="bgrundmann@janestreet.com"; x-sender="bgrundmann@janestreet.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@tot-dmz-mxout1.janestreet.com) identity=helo; client-ip=38.105.200.229; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="bgrundmann@janestreet.com"; x-sender="postmaster@tot-dmz-mxout1.janestreet.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq8BAM1hRVImacjlnGdsb2JhbABZgz9SrXeKEYhCgRYeDgEBAQEBBhYJPIIlAQEEAUABASwLAQQLCwsaISISAQUBChIGExKHYgMJBgMJm0+LDIRQAQWEUwOJbgaPTQQHhB6YAIEvjl8YKYRO X-IPAS-Result: Aq8BAM1hRVImacjlnGdsb2JhbABZgz9SrXeKEYhCgRYeDgEBAQEBBhYJPIIlAQEEAUABASwLAQQLCwsaISISAQUBChIGExKHYgMJBgMJm0+LDIRQAQWEUwOJbgaPTQQHhB6YAIEvjl8YKYRO X-IronPort-AV: E=Sophos;i="4.90,991,1371074400"; d="scan'208";a="28304094" Received: from mx5.janestreet.com (HELO tot-dmz-mxout1.janestreet.com) ([38.105.200.229]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Sep 2013 12:51:12 +0200 Received: from tot-oib-smtp1.delacy.com ([172.27.22.15] helo=tot-smtp) by tot-dmz-mxout1.janestreet.com with esmtp (Exim 4.76) (envelope-from ) id 1VPVde-0005Ge-11 for caml-list@inria.fr; Fri, 27 Sep 2013 06:51:10 -0400 Received: from tot-dmz-mxgoog1.delacy.com ([172.27.224.14] helo=mxgoog2.janestreet.com) by tot-smtp with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VPVde-0001ae-06 for caml-list@inria.fr; Fri, 27 Sep 2013 06:51:10 -0400 Received: from mail-vb0-f42.google.com ([209.85.212.42]) by mxgoog2.janestreet.com with esmtp (Exim 4.76) (envelope-from ) id 1VPVdd-0000Rp-TK for caml-list@inria.fr; Fri, 27 Sep 2013 06:51:09 -0400 Received: by mail-vb0-f42.google.com with SMTP id e12so1706701vbg.15 for ; Fri, 27 Sep 2013 03:51:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=915vft/+TnvVzBY9kygQlr7MFDh1UQAkzk01z+dWVnU=; b=v/FPI9qXaFR/1Z8mkUxvk+WiR/6+XinRImqAON9+SK87kaJtSv0O7z5TWp61CjLqVg FQPlbd42IFcrG/btEKcnzBaYGRt6HWFSp2MN1m3vRmarx8+NTWRU0ruZ8Q326Yb84EA9 i6903awVWPBes9+BJjiq1dpOpIcxS8oWo0ce0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=915vft/+TnvVzBY9kygQlr7MFDh1UQAkzk01z+dWVnU=; b=aCqI8RnAF/764ilahQsLeYYhQEIh6sUTMh0Gr2la/yKyko0Y8rmp6CP4F6jbjJhGIJ D9+nVz/24MPHJTcAyHzI0crS5aKiXPO/mj+bZ5+p91VFB6Z+rzmxg6LNoQz4KCrdNi+9 sMHyecCVlLemdA6tpcMKgjnYjy5yDSL71R0zEUZ+tjKsaAeAVrl5TTJd20SiaDD2Sz1W X7xkn05I0t6ziSAIxRJHIQnh3tSFyqvO/+W8rsY6HczfyV3I0+7zPxEao0dWhdq8vtyk E3enUF0oiUf4j9/zsHkA3aI8VMnoeEvMONpsK04bBz8LUK/2/r25ZxTRo+DwMy+k6YIE 2Ayw== X-Gm-Message-State: ALoCoQl/70wR7rx/QnTD6EAu0i3++L6I6RWaDduL1ar2ldXLYc2pzP5J78+fDe8lhJZAi35a0jOYVeUalfpmYQefi5mVyTHMvQn7nlXdkRunaV8q1gG0CLShZrOKJjJ6RH1tbRDQ8kxLILBaex4nLrK3vzM/tHIDYw== X-Received: by 10.220.47.10 with SMTP id l10mr69753vcf.32.1380279069762; Fri, 27 Sep 2013 03:51:09 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.220.47.10 with SMTP id l10mr69752vcf.32.1380279069675; Fri, 27 Sep 2013 03:51:09 -0700 (PDT) Received: by 10.58.206.69 with HTTP; Fri, 27 Sep 2013 03:51:09 -0700 (PDT) In-Reply-To: <52455D91.6000304@inria.fr> References: <52455D91.6000304@inria.fr> Date: Fri, 27 Sep 2013 11:51:09 +0100 Message-ID: From: Benedikt Grundmann To: Romain Bardou Cc: caml-list@inria.fr Content-Type: multipart/alternative; boundary=001a11c2a58ca3a71504e75b435c Subject: Re: [Caml-list] Thread behaviour --001a11c2a58ca3a71504e75b435c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The ticker thread will cause yields which will be honored on the next allocation of the thread that currently has the caml lock. That said we have seen that sometimes the lock is reacquired by the same thread again. So there are some fairness issues. On Fri, Sep 27, 2013 at 11:27 AM, Romain Bardou wro= te: > Le 27/09/2013 12:10, Tom Ridge a =E9crit : > > Dear caml-list, > > > > I have a little program which creates a thread, and then sits in a loop: > > > > -- > > > > let f () =3D > > let _ =3D ignore (print_endline "3") in > > let _ =3D ignore (print_endline "hello") in > > let _ =3D ignore (print_endline "4") in > > () > > > > let main () =3D > > let _ =3D ignore (print_endline "1") in > > let t =3D Thread.create f () in > > (* let _ =3D Thread.join t in *) > > let _ =3D ignore (print_endline "2") in > > while true do > > flush stdout; > > done > > > > let _ =3D main () > > > > -- > > > > I compile the program with the following Makefile clause: > > > > test.byte: test.ml FORCE > > ocamlc -o $@ -thread unix.cma threads.cma $< > > > > When I run the program I get the output: > > > > 1 > > 2 > > > > and the program then sits in the loop. I was expecting the output from > > f to show up as well. If you wait a while, it does. But you have to > > wait quite a while. > > > > What am I doing wrong here? I notice that if I put Thread.yield in the > > while loop then f's output gets printed pretty quickly. But why should > > the while loop affect scheduling of f's thread? > > > > Thanks > > > > OCaml's thread, unfortunately, are kind of cooperative: you need to > yield explicitly. Note that you will obtain an even different (worse) > result with a native program. I observed this myself without looking at > the thread code itself so maybe there is actually a way to > "automatically yield" but as far as I know there is no way to obtain the > behavior you want without using either yields or processes instead of > threads. This is the reason for the Procord library I am developing > (first version to be released before the next OUPS meeting). > > Also, you don't need to ignore the result of print_endline, as > print_endline returns unit. And using let _ =3D ... in is the same as > using ignore, so using both is not needed. > > Cheers, > > -- > Romain Bardou > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa.inria.fr/sympa/arc/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > --001a11c2a58ca3a71504e75b435c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The ticker thread will cause yields which will be honored = on the next allocation of the thread that currently has the caml lock.=A0 T= hat said we have seen that sometimes the lock is reacquired by the same thr= ead again.=A0 So there are some fairness issues.


On Fri,= Sep 27, 2013 at 11:27 AM, Romain Bardou <romain.bardou@inria.fr&= gt; wrote:
Le 27/09/2013 12:10, Tom Ridge a =E9crit :
> Dear caml-list,
>
> I have a little program which creates a thread, and then sits in a loo= p:
>
> --
>
> let f () =3D
> =A0 let _ =3D ignore (print_endline "3") in
> =A0 let _ =3D ignore (print_endline "hello") in
> =A0 let _ =3D ignore (print_endline "4") in
> =A0 ()
>
> let main () =3D
> =A0 let _ =3D ignore (print_endline "1") in
> =A0 let t =3D Thread.create f () in
> =A0 (* let _ =3D Thread.join t in *)
> =A0 let _ =3D ignore (print_endline "2") in
> =A0 while true do
> =A0 =A0 flush stdout;
> =A0 done
>
> let _ =3D main ()
>
> --
>
> I compile the program with the following Makefile clause:
>
> test.byte: test.ml FO= RCE
> ocamlc -o $@ -thread unix.cma threads.cma $<
>
> When I run the program I get the output:
>
> 1
> 2
>
> and the program then sits in the loop. I was expecting the output from=
> f to show up as well. If you wait a while, it does. But you have to
> wait quite a while.
>
> What am I doing wrong here? I notice that if I put Thread.yield in the=
> while loop then f's output gets printed pretty quickly. But why sh= ould
> the while loop affect scheduling of f's thread?
>
> Thanks
>

OCaml's thread, unfortunately, are kind of cooperative: you= need to
yield explicitly. Note that you will obtain an even different (worse)
result with a native program. I observed this myself without looking at
the thread code itself so maybe there is actually a way to
"automatically yield" but as far as I know there is no way to obt= ain the
behavior you want without using either yields or processes instead of
threads. This is the reason for the Procord library I am developing
(first version to be released before the next OUPS meeting).

Also, you don't need to ignore the result of print_endline, as
print_endline returns unit. And using let _ =3D ... in is the same as
using ignore, so using both is not needed.

Cheers,

--
Romain Bardou

--
Caml-list mailing list. =A0Subscription management and archives:
ht= tps://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

--001a11c2a58ca3a71504e75b435c--