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 2C16A7EE4B for ; Sun, 29 Sep 2013 18:25:27 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of tom.j.ridge@googlemail.com) identity=pra; client-ip=209.85.192.176; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="tom.j.ridge@googlemail.com"; x-sender="tom.j.ridge@googlemail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of tom.j.ridge@googlemail.com designates 209.85.192.176 as permitted sender) identity=mailfrom; client-ip=209.85.192.176; receiver=mail2-smtp-roc.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 (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-pd0-f176.google.com) identity=helo; client-ip=209.85.192.176; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="tom.j.ridge@googlemail.com"; x-sender="postmaster@mail-pd0-f176.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8CALhTSFLRVcCwlGdsb2JhbABZhBHCDggWDgEBAQEHCwsJEiqCJQEBBAFAAQE3AQ8BCgsDCi4iEgEFARwGE4dzAQMJBp0riwyEUAEFg2MKGScNiWQGk3qYApAPGCmBYoJsOw X-IPAS-Result: Ak8CALhTSFLRVcCwlGdsb2JhbABZhBHCDggWDgEBAQEHCwsJEiqCJQEBBAFAAQE3AQ8BCgsDCi4iEgEFARwGE4dzAQMJBp0riwyEUAEFg2MKGScNiWQGk3qYApAPGCmBYoJsOw X-IronPort-AV: E=Sophos;i="4.90,1005,1371074400"; d="scan'208";a="34794528" Received: from mail-pd0-f176.google.com ([209.85.192.176]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 29 Sep 2013 18:25:25 +0200 Received: by mail-pd0-f176.google.com with SMTP id q10so4611060pdj.21 for ; Sun, 29 Sep 2013 09:25:24 -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:cc:content-type; bh=FV+0j1ujh/Ss6+Q7OQO0W+HBssRyC9erxI1/AeF7Xeg=; b=vP9tvHJHTZOxh9OligyRSKqk3uI2Ed5ZcO1ujVTfa5z0wdB/gb7/i0Dj9geRWMZ8BD tRxgkTyO8+hUX7ym+tKDx/e37oFGVjebr/mvobJ8j54fsdq1NPVqNAu7iLWuUCl9q04u sPMhGQTWGibzIu/UgxXx3oBjlCdgf0iPmVqXwI51/ASfzGd4sZ+Wlr9rl6oVJ6IXZnkE 71MmtsEVX3zhB7VOYyYv5UZGK4PKX1Kt8WGM7cTFHoBNBora0j9o7RPRPR4pS2lGIQxv NSdmnyBbBJuLMHgZaThyNM2NkV0CMZJ4mZZzGXW5x7oFAPOFJODQEeYlnTCNKQpJI+gG j+BA== X-Received: by 10.68.160.130 with SMTP id xk2mr19165778pbb.7.1380471924765; Sun, 29 Sep 2013 09:25:24 -0700 (PDT) MIME-Version: 1.0 Sender: tom.j.ridge@googlemail.com Received: by 10.70.79.136 with HTTP; Sun, 29 Sep 2013 09:25:04 -0700 (PDT) In-Reply-To: References: <52455D91.6000304@inria.fr> From: Tom Ridge Date: Sun, 29 Sep 2013 17:25:04 +0100 X-Google-Sender-Auth: iAYJlEHC8SyGGSutR0WpvbNPA3Q Message-ID: To: Yaron Minsky Cc: caml-list Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Caml-list] Thread behaviour On 29 September 2013 13:37, Yaron Minsky wrote: > I think you've come away with the wrong conclusion. Here's my summary > of the state of play. > > OCaml has a single runtime lock, but _does_ support pre-emptive OS > threads. You can use them for concurrency but not parallelism. Code > that runs in a tight loop in one thread, though, can starve another > thread, particularly if it doesn't allocate, because OCaml only gives > up the runtime lock when it allocates. 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? > > You should probably avoid direct use of threads for concurrent > programming. Monadic concurrency libraries like lwt or async are the > way to go. You can definitely build message-passing libraries on top > of these, and many have. Could you provide some pointers to these libraries? I would be very interested in this. One thing I didn't immediately see how to do, when reading the Lwt docs, was to provide a user interface (connect, send, recv etc) that did not expose the fact that co-operative threads were in the background. It also seems to me that if someone uses my library with their code, and their code itself uses Lwt, then there is the possibility for strange interactions (my Lwt threads are not isolated from their Lwt threads; with system threads and system-provided pre-emptive scheduling, you (maybe) do get some isolation/fairness properties). > > You can also build such libraries against raw threads, but I would recommend. > > None of which is to argue that you shouldn't use a binding of some > non-OCaml message-passing library. I've heard excellent things about > zeromq,which has bindings in opam. OK! So +1 for zeromq. I will check it out. Any votes for any other libraries? OCamlMPI? BTW thanks to everyone for taking the time to respond to these questions, and apologies for my ignorance. T