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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 8365ABB84 for ; Wed, 21 May 2008 15:49:17 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArgAAHzEM0jU436ulGdsb2JhbACBVZBgAQEBAQkDCgcRA51JAQ X-IronPort-AV: E=Sophos;i="4.27,520,1204498800"; d="scan'208";a="10958702" Received: from discorde.inria.fr ([192.93.2.38]) by mail2-smtp-roc.national.inria.fr with ESMTP; 21 May 2008 15:49:17 +0200 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id m4LDnGmw006461 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Wed, 21 May 2008 15:49:17 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArgAAHzEM0jU436ulGdsb2JhbACBVZBgAQEBAQkDCgcRA51JAQ X-IronPort-AV: E=Sophos;i="4.27,520,1204498800"; d="scan'208";a="10958700" Received: from moutng.kundenserver.de ([212.227.126.174]) by mail2-smtp-roc.national.inria.fr with ESMTP; 21 May 2008 15:49:17 +0200 Received: from gate.lan.gerd-stolpmann.de (dslb-084-059-100-000.pools.arcor-ip.net [84.59.100.0]) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis) id 0ML21M-1Jyogt3iq3-0000Th; Wed, 21 May 2008 15:49:16 +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 750D1C074; Wed, 21 May 2008 15:49:15 +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 In-Reply-To: <4833D7E8.8060502@doc.ic.ac.uk> References: <200805181735.50621.jon@ffconsultancy.com> <4831686F.8010903@doc.ic.ac.uk> <1211206144.11053.15.camel@flake.lan.gerd-stolpmann.de> <4833D7E8.8060502@doc.ic.ac.uk> Content-Type: text/plain Date: Wed, 21 May 2008 15:50:34 +0200 Message-Id: <1211377834.16959.20.camel@flake.lan.gerd-stolpmann.de> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX1+8J/4KB6AsTbvxbPuuB0BkQXQN1OAjCnXAxj3 Vn40jfgsJTq5C5esYfySsUf6UH0IXITCxcSJMN71CTv98/8e/n Ka0tZiN2aC8/WMXInn8Km/RgiBCDIGs X-Miltered: at discorde with ID 4834285C.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; gerd:01 stolpmann:01 logics:01 inherently:01 freezes:01 o'caml:01 gerd:01 stolpmann:01 viktoriastr:01 64293:01 darmstadt:01 6151:01 6151:01 quicker:98 typing:01 Am Mittwoch, den 21.05.2008, 09:06 +0100 schrieb Martin Berger: > 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. But this is still academic, right? The practice is that there is almost no utility that helps programmers to write (more) correct code. > 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. Of course, it is possible to e.g. develop locking mechanism in event handling programs, and then to run into the same problems. My experience is different, however. The worst thing I've encountered so far in practice is the "forgotten continuation" so that the event system freezes. Another result from using this is in practice is that it is comparatively easy to debug synchronization problems, because the debugging code is not itself concurrent code. This is different to e.g. multi-threaded programs where the whole program is concurrent, and you cannot locally escape from this environment. > > 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. Granted, "cannot run into deadlocks" is too strong. > > 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. Well, it's probably one of the biggest programs that has ever been coded in O'Caml... It's a search engine (wink.com), and I would say it is very demanding in terms of concurrency. Keep in mind that I am not a researcher. When I make statements, then from a practical point of view. My observation is simply that you run far quicker into complicated synchronization problems with shared memory concurrency than with the types of concurrency I prefer. Gerd -- ------------------------------------------------------------ Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany gerd@gerd-stolpmann.de http://www.gerd-stolpmann.de Phone: +49-6151-153855 Fax: +49-6151-997714 ------------------------------------------------------------