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.1 required=5.0 tests=AWL 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 AD6D5BB84 for ; Mon, 19 May 2008 16:07:48 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8BAK8lMUjAXQImiGdsb2JhbACBVZBaAQEBDyCZVgE X-IronPort-AV: E=Sophos;i="4.27,509,1204498800"; d="scan'208";a="12754869" Received: from discorde.inria.fr ([192.93.2.38]) by mail3-smtp-sop.national.inria.fr with ESMTP; 19 May 2008 16:07:47 +0200 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id m4JE7lml022981 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Mon, 19 May 2008 16:07:47 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtgAANomMUjU436rlGdsb2JhbACBVZBaAQEBAQkDCgcRA5lpAQ X-IronPort-AV: E=Sophos;i="4.27,509,1204498800"; d="scan'208";a="26346781" Received: from moutng.kundenserver.de ([212.227.126.171]) by mail4-smtp-sop.national.inria.fr with ESMTP; 19 May 2008 16:07:47 +0200 Received: from gate.lan.gerd-stolpmann.de (dslb-084-059-097-241.pools.arcor-ip.net [84.59.97.241]) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis) id 0ML2xA-1Jy61h32Xo-0005Ki; Mon, 19 May 2008 16:07:45 +0200 Received: from [192.168.0.32] (fw.lan.gerd-stolpmann.de [192.168.1.1]) by gate.lan.gerd-stolpmann.de (Postfix) with ESMTP id 5ECACC074; Mon, 19 May 2008 16:07:45 +0200 (CEST) Subject: Re: [Caml-list] Re: Where's my non-classical shared memory concurrency technology? From: Gerd Stolpmann To: Martin Berger Cc: caml-list@inria.fr In-Reply-To: <4831686F.8010903@doc.ic.ac.uk> References: <200805181735.50621.jon@ffconsultancy.com> <4831686F.8010903@doc.ic.ac.uk> Content-Type: text/plain Date: Mon, 19 May 2008 16:09:04 +0200 Message-Id: <1211206144.11053.15.camel@flake.lan.gerd-stolpmann.de> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX1881GjGIOlZje8oP9DGFTlJI2R+f+S9BxnXVHR nnxvh75BeLK2WRTzmLyWUaaZT9EGqXBLLBhVNIPsOS+LIYdhD7 UuPT8k1FbzL/KYcim0IaItoTtWcRvLk X-Miltered: at discorde with ID 483189B3.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; gerd:01 stolpmann:01 ocamlnet:01 inherently:01 fairness:01 non-trivial:01 gerd:01 parallelism:01 beginner's:01 ocaml:01 bug:01 stolpmann:01 viktoriastr:01 64293:01 darmstadt:01 Am Montag, den 19.05.2008, 12:45 +0100 schrieb Martin Berger: > Jon Harrop wrote: > > >> Similarly, avoiding threads removes concurrency bugs... > > > I don't believe you have removed any concurrency bugs. I think you just pushed > > them around a bit. > > I couldn't agree more. If you 'avoid' concurrency by writing your own > 'sequential' event handling code, you have not removed the concurrency, > you just face it in a slightly different form, and you have to > program the event handling code yourself, I cannot agree. Just use Ocamlnet! Or other libraries doing it for you. > rather than relying > on a tried and tested library, 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. Event handing concurrency, while not giving you parallelization, is basically sequential programming, and it is possible to reason about such programs. 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. > i.e. you have an additional > source of bugs, without removing the problems that are inherent > in concurrency (e.g. deadlocks, livelocks, fairness ...). 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. > There > are reasons why writing your own concurrency mechanisms might > be the way to go, but it's a highly non-trivial endeavor. Maybe in a mainstream language, but in FP I found it always relatively easy to do it. > Concurrency is hard, and no matter how one presents the concurrency > (message passing, shared memory, event handling etc), the fundamental > problems will always be there. As pointed out, I cannot agree with your premises. There are different types of concurrency built on top of different fundaments. Gerd > > > Data parallelism in Microsoft's Task Parallel Library. I have no > > use for STM myself. > > Do you have industrial experience with STM? I wonder how it > performs in industrial settings. Reading STM papers by their > inventors makes them sound like the best thing since sliced > bread, but I have a (probably irrational) feeling that it's > difficult to beat fine grained locking if one can handle > the programming difficulties their use imposes. > > Martin Berger > > > _______________________________________________ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > -- ------------------------------------------------------------ Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany gerd@gerd-stolpmann.de http://www.gerd-stolpmann.de Phone: +49-6151-153855 Fax: +49-6151-997714 ------------------------------------------------------------