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 92A647EE4B for ; Sun, 29 Sep 2013 18:46:40 +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.49; 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.49 as permitted sender) identity=mailfrom; client-ip=209.85.216.49; 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-f49.google.com) identity=helo; client-ip=209.85.216.49; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="murthy.chet@gmail.com"; x-sender="postmaster@mail-qa0-f49.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmkRAKpYSFLRVdgxlGdsb2JhbABZiWm7HoEgFg4BAQEBBwsLCRIqgiUBAQQBJxMGARsdAQMBCwYFIRUQDwETEQEFARwGAYgFAQMJBp0yjFKDCoNpChknDWSJAAEFDI9FB4QiA4k5nlVBhG2BSCM X-IPAS-Result: AmkRAKpYSFLRVdgxlGdsb2JhbABZiWm7HoEgFg4BAQEBBwsLCRIqgiUBAQQBJxMGARsdAQMBCwYFIRUQDwETEQEFARwGAYgFAQMJBp0yjFKDCoNpChknDWSJAAEFDI9FB4QiA4k5nlVBhG2BSCM X-IronPort-AV: E=Sophos;i="4.90,1005,1371074400"; d="scan'208";a="28465984" Received: from mail-qa0-f49.google.com ([209.85.216.49]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 29 Sep 2013 18:46:39 +0200 Received: by mail-qa0-f49.google.com with SMTP id k15so1709964qaq.15 for ; Sun, 29 Sep 2013 09:46:38 -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=vGVq4rX7dH5u9FLnYWs9w/4pyJLLAtTOVzxdiQUiSHs=; b=MgGVqubdWOq9FSUKd0bRAynSO+K6q75TCcqLX6bOu5vkbz03LAnveYMNaNir1eJfrP TGhqM9psTuFjxr1irMEKOmBxMUqEoJpkeTtcFDFGJmdzrJo3CPkRehUKn/m8vC20nV46 qaiHA5KdVMy6f6oYlextQuPEUv5e4OhpTfrQeG5/+qCzv5L0ojijT22Qdsn+8+xLoZy6 0omjjW8AGDMj0J+jvsPgGMTa2/P9SevdfOAGyGnuFFwTUwqnj5auGY0ruyJ2zam3hpMz Ha0m600kzUgVZMslBLzoK3ObkA2PVEMBNQtYzmKBrdyUv4AnX3y2MaOs+Frs5s1beczM l0bQ== X-Received: by 10.49.27.137 with SMTP id t9mr22987606qeg.70.1380473198544; Sun, 29 Sep 2013 09:46:38 -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 a7sm33310895qew.2.1969.12.31.16.00.00 (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 29 Sep 2013 09:46:37 -0700 (PDT) From: Chet Murthy To: caml-list@inria.fr, Tom Ridge Cc: Yaron Minsky Date: Sun, 29 Sep 2013 09:46:35 -0700 Message-ID: <23010395.NVkQDdK53E@groupon> User-Agent: KMail/4.10.5 (Linux/3.8.0-31-generic; KDE/4.10.5; i686; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [Caml-list] Thread behaviour > 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. "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 [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)] "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". 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. Does this help? --chet--