From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 2FC367EE4B for ; Sun, 29 Sep 2013 19:47:51 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of murthy.chet@gmail.com) identity=pra; client-ip=209.85.216.50; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="murthy.chet@gmail.com"; x-sender="murthy.chet@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of murthy.chet@gmail.com designates 209.85.216.50 as permitted sender) identity=mailfrom; client-ip=209.85.216.50; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="murthy.chet@gmail.com"; x-sender="murthy.chet@gmail.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@mail-qa0-f50.google.com) identity=helo; client-ip=209.85.216.50; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="murthy.chet@gmail.com"; x-sender="postmaster@mail-qa0-f50.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmkRAO1mSFLRVdgylGdsb2JhbABZiWm7HoEgFg4BAQEBBwsLCRIqgiUBAQQBOgYBGx0BAwELBgUhFRAPARMRAQUBHAaIBgEDCQadQoxSgwqDaQoZJw1kiQABBQyPRQeEIgOJOYppk2xBhG0 X-IPAS-Result: AmkRAO1mSFLRVdgylGdsb2JhbABZiWm7HoEgFg4BAQEBBwsLCRIqgiUBAQQBOgYBGx0BAwELBgUhFRAPARMRAQUBHAaIBgEDCQadQoxSgwqDaQoZJw1kiQABBQyPRQeEIgOJOYppk2xBhG0 X-IronPort-AV: E=Sophos;i="4.90,1005,1371074400"; d="scan'208";a="28468314" Received: from mail-qa0-f50.google.com ([209.85.216.50]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 29 Sep 2013 19:47:50 +0200 Received: by mail-qa0-f50.google.com with SMTP id j7so1743255qaq.9 for ; Sun, 29 Sep 2013 10:47:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding:content-type; bh=syHkFEZzQIaykkl2200RGlt+WHlMWgDfQOjuqRtNySw=; b=Pg9N+m1ZjB8tSMLntJyLBrWuI0mB9dOmEUtv1CSR5oOYoDJk4XTz9cvqfpA7/Htp1K 2ZCnHt+gcTzOFYnzhKI66WjlRE88DzCw9m4agBQi23jvbQSuheyouXbAT3Un0vA5JgJ0 oGLGz4MfE9GKouhXy8f3rwBLbe76+wH6/F5Fup0pygWWYIG7rtEUqTDxRqmgONSZB2Ef 06OfRpSVX2PlbXZjmZjsB9fr4fSUNLmFFhslnJzc2jjmL2zKpZo5JWeaauVxm4hTWtUn ALrtJDMMyTFILOaNcK6EHDfVC86RV7KSfkH4hEigEhU4D5Ct62JwKTWs+zH+GY2yAXdA raVw== X-Received: by 10.49.2.68 with SMTP id 4mr23597770qes.64.1380476869182; Sun, 29 Sep 2013 10:47:49 -0700 (PDT) Received: from groupon.localnet (adsl-99-175-102-233.dsl.pltn13.sbcglobal.net. [99.175.102.233]) by mx.google.com with ESMTPSA id l4sm33706934qae.4.1969.12.31.16.00.00 (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 29 Sep 2013 10:47:48 -0700 (PDT) From: Chet Murthy To: Tom Ridge Cc: caml-list Date: Sun, 29 Sep 2013 10:47:46 -0700 Message-ID: <1402586.FfBdj3Dhrj@groupon> User-Agent: KMail/4.10.5 (Linux/3.8.0-31-generic; KDE/4.10.5; i686; ; ) In-Reply-To: References: <23010395.NVkQDdK53E@groupon> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [Caml-list] Thread behaviour > 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. --chet--