From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 3C5A97EE4C for ; Mon, 7 Oct 2013 16:57:52 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of goswin-v-b@web.de) identity=pra; client-ip=212.227.15.4; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="goswin-v-b@web.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of goswin-v-b@web.de) identity=mailfrom; client-ip=212.227.15.4; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="goswin-v-b@web.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mout.web.de) identity=helo; client-ip=212.227.15.4; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="postmaster@mout.web.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsCABXLUlLU4w8EeWdsb2JhbABZv2+CQ4J5gR4WDgEBCQsLCTyCJQEBBTIBVgsYCSUPBSiIJwEWsAQfiiOPWBaDCYEEA5Qkg1yGI48E X-IPAS-Result: ArsCABXLUlLU4w8EeWdsb2JhbABZv2+CQ4J5gR4WDgEBCQsLCTyCJQEBBTIBVgsYCSUPBSiIJwEWsAQfiiOPWBaDCYEEA5Qkg1yGI48E X-IronPort-AV: E=Sophos;i="4.90,1050,1371074400"; d="scan'208";a="35918499" Received: from mout.web.de ([212.227.15.4]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 07 Oct 2013 16:57:50 +0200 Received: from frosties.localnet ([95.208.119.3]) by smtp.web.de (mrweb004) with ESMTPSA (Nemesis) id 0MVXnr-1VIztB4AUp-00Z3R1 for ; Mon, 07 Oct 2013 16:57:51 +0200 Received: from mrvn by frosties.localnet with local (Exim 4.80) (envelope-from ) id 1VTCFq-0000eD-GY for caml-list@inria.fr; Mon, 07 Oct 2013 16:57:50 +0200 Date: Mon, 7 Oct 2013 16:57:50 +0200 From: Goswin von Brederlow To: caml-list@inria.fr Message-ID: <20131007145750.GB2035@frosties> References: <23010395.NVkQDdK53E@groupon> <1402586.FfBdj3Dhrj@groupon> <52493521.4000204@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <52493521.4000204@inria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) X-Provags-ID: V03:K0:1GfjrlZlMF8MR9EJ1H1aLvyiPCPNzGIyd8QBP0a2MNDssIRbI1h cxdCA3kUeFywg345Xo3ZBR7wZrKlTpmGH3cyK8Dc/zglo6cvZD0TGlR+xeFulYibAZqxQbW 0m3k9Lo6u6tSaj4GbytBoAGjSmkVpkHIwhtZYMXD3W0cBrChteRijHXRvD+Q9ICFVTmYwNt dSLiQK+aQ6Esl1qokuutQ== Subject: Re: [Caml-list] Thread behaviour On Mon, Sep 30, 2013 at 10:24:01AM +0200, Romain Bardou wrote: > Le 29/09/2013 19:47, Chet Murthy a écrit : > > > >> This is my situation. I don't care if the code runs on a single core > >> (in fact, I hope it does), but I do want to use threads which are > >> scheduled reasonably independently and reasonably fairly. My first > >> example shows that one thread is effectively starved by the other > >> thread. > > > > Ah. ok. In this case, it's easier. You just need to ensure that in > > every loop,in every recursive function, there's a call to something > > that yield()s, on every path. It's that simple, and that icky. But > > then, if you have code that literally doesn't do anything that yields, > > in a loop, it's compute-intensive, and -that- means you're not really > > asking for concurrency, are you? > > > > BTW, to your original question "why should the while loop affect > > scheduling of f's thread": because there is a global operation > > (scheduling) that needs cooperation from all threads in order to > > execute. And that requires explicit coding by the programmer. Now, > > the compiler -could- have inserted code to do the yield() (in some old > > LISPms, it was done at every backward jump and return, I think). > > > > I can't speculate as to why it wasn't done, but given that the goal of > > ocaml's threads is concurrency, and not parallelism, it isn't common > > (at least, in my experience) to write code that doesn't naturally > > reach yield points frequently. > > Unfortunately there is a huge class of such kind of code: code which > uses libraries which do not yield. For instance, code which loads a DLL > to communicate with hardware and which may block (or worse). > > Cheers, But that coulde would be external and you would release the global lock before the blocking call. That's what e.g. Unix.write does. You can have many threads that run in parallel. But only one at a time can run ocaml code. All others can only run external code. Also your example was bad because in real code you wouldn't (shouldn't) have a busy loop that does nothing without at least a yield in it. You assumed the flush would do something that triggeres the scheduler but that doesn't seem to be the case if the buffer is empty. Kind of makes sense. If there is nothing to flush then the call just returns and nothing happens. Only when there is something to flush it writes data, releasing the runtime lock and scheduling as a side effect. MfG Goswin PS: Tip: Use Printf.printf "...%!"