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.2 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 9A228BB84 for ; Tue, 20 May 2008 12:51:12 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnIAAD9JMkjBtPs8mmdsb2JhbACSMAEBAQEBBgcIBxEFmyo X-IronPort-AV: E=Sophos;i="4.27,515,1204498800"; d="scan'208";a="10907360" Received: from concorde.inria.fr ([192.93.2.39]) by mail2-smtp-roc.national.inria.fr with ESMTP; 20 May 2008 12:51:12 +0200 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id m4KAp9QV017757 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Tue, 20 May 2008 12:51:12 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnIAAD9JMkjBtPs8mmdsb2JhbACSMAEBAQEBBgcIBxEFmyo X-IronPort-AV: E=Sophos;i="4.27,515,1204498800"; d="scan'208";a="10907358" Received: from mailgw3.ericsson.se ([193.180.251.60]) by mail2-smtp-roc.national.inria.fr with ESMTP; 20 May 2008 12:51:11 +0200 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0382720976; Tue, 20 May 2008 09:40:16 +0200 (CEST) X-AuditID: c1b4fb3c-ad89abb00000193b-5c-4832805fdb62 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D5DB9208BF; Tue, 20 May 2008 09:40:15 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 May 2008 09:40:10 +0200 Received: from ws73032.uab.ericsson.se ([130.100.73.32]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 May 2008 09:40:10 +0200 Received: from [153.88.16.254] by ws73032.uab.ericsson.se (8.11.7p2+Sun/client-1.3uab4) id m4K7e9a08748; Tue, 20 May 2008 09:40:09 +0200 (MEST) Message-ID: <48328059.2070007@ericsson.com> Date: Tue, 20 May 2008 09:40:09 +0200 From: "Ulf Wiger (TN/EAB)" User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Gerd Stolpmann Cc: Martin Berger , caml-list@inria.fr 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-OriginalArrivalTime: 20 May 2008 07:40:10.0034 (UTC) FILETIME=[BB289920:01C8BA4C] X-Brightmail-Tracker: AAAAAA== X-Miltered: at concorde with ID 4832AD1D.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; gerd:01 stolpmann:01 erlang:01 synchronous:01 event-based:01 parallelism:01 event-based:01 mutexes:01 parallelism:01 model:01 wholly:98 handset:98 threads:01 caml-list:01 data:02 Gerd Stolpmann skrev: > > This is simply nonsense. Different concurrency techniques > have different problems. True. > For example, in event > handling-based concurrency you do not need locks, hence > you cannot run into deadlocks. Yes you can. We've even had to write design rules to this effect to educate our commercial Erlang programmers. There seems to be a common belief that switching from synchronous to asynchronous communication will eliminate the risk for deadlock, but just like Jon noted, if two threads/processes wait for events from the other processes, they may deadlock*. Using asynchronous programming just makes the deadlock much more difficult to detect, than if the processes communicate synchronously. * In the sense that neither can continue. Deadlock doesn't require the presence of locks at all. Going back to Jon's observation that you cannot exploit multicore with event-based programming, I'm inclined to agree, even though I think that message-passing concurrency is quite suitable for making use of multiple cores (albeit addressing a wholly different problem from data parallelism). The problem with event-based programming is that it doesn't scale complexity-wise, and just as when programming with mutexes, introducing true parallelism just makes it worse. While there may be some simple applications which actually can scale up this way, doing so with more "interesting" concurrency patterns is courting disaster. I could list some juicy examples of important commercial products that are limited to a single core for this very reason, but alas I'm not permitted to. I have to ask you to take my word for it. When scaling up message-passing (or event-based) concurrency, you have to do one of two things: 1) ensure that your code is stable in the face of timing variations and message reordering 2) calculate the entire event/state matrix For hard real-time, you must do (2) anyway. For soft real-time, you don't have to, since a missed deadline can be viewed as a temporary glitch rather than a system error. And (2) suffers from the same problems as model checking - it doesn't scale well. For a phone system (soft real-time), if you pick up the phone and don't get dial tone, you replace the handset, then pick it up again - normally, it will work then. Everyone's experienced this, and it doesn't bother us unless it happens often. Similarly, we can accept if it occasionally takes a few seconds longer than usual. The same behavior would be extremely unnerving - possibly fatal - if the breaks on your car (hard real-time) started exhibiting it. BR, Ulf W