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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 21A1F7EE4B for ; Mon, 30 Sep 2013 10:24:07 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.90,1006,1371074400"; d="scan'208";a="34859346" Received: from dhcp-rocq-121.inria.fr (HELO [128.93.62.121]) ([128.93.62.121]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 30 Sep 2013 10:24:05 +0200 Message-ID: <52493521.4000204@inria.fr> Date: Mon, 30 Sep 2013 10:24:01 +0200 From: Romain Bardou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: caml-list@inria.fr References: <23010395.NVkQDdK53E@groupon> <1402586.FfBdj3Dhrj@groupon> In-Reply-To: <1402586.FfBdj3Dhrj@groupon> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Validation-by: romain.bardou@inria.fr Subject: Re: [Caml-list] Thread behaviour 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, -- Romain Bardou