From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 18407BB84 for ; Wed, 21 May 2008 10:06:03 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlIBAFV0M0iKJV+LgWdsb2JhbACSNgEBECAFnTI X-IronPort-AV: E=Sophos;i="4.27,519,1204498800"; d="scan'208";a="12858378" Received: from discorde.inria.fr ([192.93.2.38]) by mail3-smtp-sop.national.inria.fr with ESMTP; 21 May 2008 10:06:02 +0200 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id m4L85n7f022909 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Wed, 21 May 2008 10:06:02 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlIBAFV0M0iKJV+LgWdsb2JhbACSNgEBECAFnTI X-IronPort-AV: E=Sophos;i="4.27,519,1204498800"; d="scan'208";a="12858377" Received: from tart.dcs.qmul.ac.uk (HELO mail.dcs.qmul.ac.uk) ([138.37.95.139]) by mail3-smtp-sop.national.inria.fr with ESMTP; 21 May 2008 10:06:02 +0200 Received: from new8-pc.dcs.qmul.ac.uk ([138.37.88.113]) by mail.dcs.qmul.ac.uk with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1JyjKi-0007b0-Nu; Wed, 21 May 2008 09:06:02 +0100 Message-ID: <4833D7E8.8060502@doc.ic.ac.uk> Date: Wed, 21 May 2008 09:06:00 +0100 From: Martin Berger User-Agent: Thunderbird 1.5.0.9 (X11/20070212) MIME-Version: 1.0 To: Gerd Stolpmann , caml-list Subject: Re: [Caml-list] Re: Where's my non-classical shared memory concurrency technology? References: <200805181735.50621.jon@ffconsultancy.com> <4831686F.8010903@doc.ic.ac.uk> <1211206144.11053.15.camel@flake.lan.gerd-stolpmann.de> In-Reply-To: <1211206144.11053.15.camel@flake.lan.gerd-stolpmann.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCS-Interface-Port: 465 X-DCS-Auth-User: martinb (person) X-Miltered: at discorde with ID 4833D7DD.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; gerd:01 stolpmann:01 ocamlnet:01 logics:01 inherently:01 wrote:01 typing:01 caml-list:01 essentially:02 checking:02 bugs:03 programming:03 locks:03 concurrency:04 concurrency:04 Gerd Stolpmann wrote: > I cannot agree. Just use Ocamlnet! Or other libraries doing it for you. OK I was speaking carelessly. Of course one can use libraries for e.g. event-handling. > On the contrary: Shared memory parallelization has the fundamental > disadvantage that you cannot reason about it, and so the only way of > checking the quality of the code is testing. Here I disagree. Shared memory concurrency is a specific form of message passing: Writing to a memory cell is in fact sending a message to that cell carrying two items, the new value and a return channel that is used to inform the writer that sending has succeeded, and likewise for reading. This way of thinking about shared memory concurrency has enabled the construction of powerful logics and typing systems to reason about shared memory. I agree with the spirit of your claim though: shared memory is a form of message passing that is especially difficult. > With "reasoning" I don't necessarily mean formal techniques. The more > frequent case is that the programmer thinks about the program guided by > the laws of logic. > > The impossibility to do this with truly parallelized code is an > important source of bugs, so I would say this code inherently more > buggy. There is a lot of truth in what you say, but if you consider complex event handling programs, you essentially do concurrent programming, wether you like it or not. You just don't call it by that name. > This is simply nonsense. Different concurrency techniques have different > problems. For example, in event handling-based concurrency you do not > need locks, hence you cannot run into deadlocks. I disagree, but as the issue has already been dealt with by other posters, I shall leave it at that. > Maybe in a mainstream language, but in FP I found it always relatively > easy to do it. Maybe you are an especially skilled programmer. Or maybe the applications that you have coded are not demanding in terms of concurrency. Martin