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 516627EE4B for ; Sun, 29 Sep 2013 19:18:39 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of tom.j.ridge@googlemail.com) identity=pra; client-ip=209.85.160.46; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="tom.j.ridge@googlemail.com"; x-sender="tom.j.ridge@googlemail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of tom.j.ridge@googlemail.com designates 209.85.160.46 as permitted sender) identity=mailfrom; client-ip=209.85.160.46; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="tom.j.ridge@googlemail.com"; x-sender="tom.j.ridge@googlemail.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-pb0-f46.google.com) identity=helo; client-ip=209.85.160.46; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="tom.j.ridge@googlemail.com"; x-sender="postmaster@mail-pb0-f46.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am4BAKtfSFLRVaAum2dsb2JhbABZhBHCDggWDgEBAQEBBgsLCRQogiUBAQQBJxkBATgECwEKCw0uIQESAQUBHAYBEodzAQMJBp09iwyEUAEFg2EKGScNiWQGjGaHFJYZgWmMRYNKGCmBYoJsO4EsIw X-IPAS-Result: Am4BAKtfSFLRVaAum2dsb2JhbABZhBHCDggWDgEBAQEBBgsLCRQogiUBAQQBJxkBATgECwEKCw0uIQESAQUBHAYBEodzAQMJBp09iwyEUAEFg2EKGScNiWQGjGaHFJYZgWmMRYNKGCmBYoJsO4EsIw X-IronPort-AV: E=Sophos;i="4.90,1005,1371074400"; d="scan'208";a="28467143" Received: from mail-pb0-f46.google.com ([209.85.160.46]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 29 Sep 2013 19:18:38 +0200 Received: by mail-pb0-f46.google.com with SMTP id rq2so4559372pbb.5 for ; Sun, 29 Sep 2013 10:18:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=6rMEbNK+0h7YsJv5xCdx3aN8oOzAFs8NjBBEJbBYp9I=; b=F24oEdXXJE0FG7I/eb1dN7hFp/lbmb8digKrIS2b3XvKSTzUmkGibEwKH0URBUtU/2 7rduW0icuq0QK/Tvx6UuBQLnyNbT3vfd151D9kMy0LHBNQaqBZUHpzGAyFWc4ix4GBh3 tskqy/2kTtv/Kv8tTUswib30WF7UdpRgyy+AWhs9gkY4uMLF0/OwG3Feuo44CsvOfd/f lN0MukVrRu8ILQH015OOqpnJa5uuImYyTp0LCFKd9Ss5Nff3ZQJ3YVroCv04ou0nMKun jwkqCkynoOjVe/0XifG7OE9+PkWNd/5BWVaym4VPovR8PvRARBXms+UE3rQWtF8qxkc8 ShWw== X-Received: by 10.67.21.226 with SMTP id hn2mr23810174pad.69.1380475116679; Sun, 29 Sep 2013 10:18:36 -0700 (PDT) MIME-Version: 1.0 Sender: tom.j.ridge@googlemail.com Received: by 10.70.79.136 with HTTP; Sun, 29 Sep 2013 10:18:16 -0700 (PDT) In-Reply-To: <23010395.NVkQDdK53E@groupon> References: <23010395.NVkQDdK53E@groupon> From: Tom Ridge Date: Sun, 29 Sep 2013 18:18:16 +0100 X-Google-Sender-Auth: lC62U8D4YHAl9hTbLt9sA_ILFRI Message-ID: To: Chet Murthy , caml-list Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Caml-list] Thread behaviour Hi Chet, On 29 September 2013 17:46, Chet Murthy wrote: > >> OK, but this means that I can't think of OCaml code running in >> different threads in a simple way - I have to consider the single >> runtime lock at least (if I care about performance). So maybe the >> question is: how should I understand the functioning of the single >> runtime lock? For example, is starvation the only thing I need to >> think about? > > Tom, > > Yaron's note made a careful distinction between two things: > "concurrency" and "performance". Let me explain a little more what > he's getting at. I sort-of understand what people mean by concurrency and *parallelism*. Parallelism is e.g. trying to use multiple CPUs. Concurrency is using constructs like threads etc. I think these words aren't the best choice if trying to make this distinction, but that is another issue. > > "concurrency" means writing programs using constructs that look like > concurrent execution, for the purpose of .... well, for whatever > purpose you'd like, but usually modularity. > > --> in short, you don't care if your code's running on a single > processor -- you just want to -write- it with multiple threads 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. > > [of course, here you care about -starvation-, hence the worry about > a tight loop with no possibility of suspension/"releasing the global > lock"; but let's set that aside, since it's a different concern > (even the LISPm, from what I remember, had issues here -- heck, so > do some JVMs, for GC)] This is my concern! I want to understand what the issues are with running code which uses multiple threads (from OCaml's Thread lib), on a single core, given that there is a global lock. > > "parallelism" means exploiting hardware facilities to -run- code in > parallel, usually for purposes of performance. > > --> you care very much if your code "properly" exploits > SMP/multicore parallelism > > When you speak of "performance", I'm going to guess that you're really > speaking of "parallelism" and not "concurrency". No! I really am talking about concurrency. I am a firm believer that message-passing is a very good way to utilize multiple cores. What I want is to implement a message passing library, using multi-threading, on a single core. I want to understand the issues that the single runtime lock can cause when trying to do this. My naive idea is that different threads execute as they would, say, using POSIX threads in C. But the presence of the single runtime lock means that threads do not behave like this (the code I started this thread off with illustrates this). So how do they behave? > If so, Ocaml's > threads are not for you, nor are monadic programming constructs. Not > merely effectively, but -by- -construction- any threading system with > a global lock can only use a single CPU. You can get more than that > from Ocaml, if Ocaml threads, spend a lot of time in C/C++ code that's > CPU-intensive. But I'm assuming that that's not what you're looking > to do. I didn't quite get that last sentence, but yes, I understand what you are saying. I really do want to understand how to think about my code, which uses OCaml Thread threads, on a single core, given that there is a global lock. Now, it may be that to understand this there is no more abstract approach than looking at the OCaml implementation. That is fine. But it may be that people will say "the only problem you can have is starvation, and you can avoid that by ensuring that each of your threads calls Thread.yield() sufficiently often". That would be a nice answer to have! Thanks T