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 EE288BB84 for ; Mon, 19 May 2008 13:46:37 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8BABoFMUjAXQImiGdsb2JhbACBVZBaAQEBDyCZJQ X-IronPort-AV: E=Sophos;i="4.27,508,1204498800"; d="scan'208";a="12748258" Received: from discorde.inria.fr ([192.93.2.38]) by mail3-smtp-sop.national.inria.fr with ESMTP; 19 May 2008 13:46:37 +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 m4JBkacn015947 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Mon, 19 May 2008 13:46:37 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMCAN8EMUiKJV+LgWdsb2JhbACBVZBaAQEQIJkj X-IronPort-AV: E=Sophos;i="4.27,508,1204498800"; d="scan'208";a="26339348" Received: from tart.dcs.qmul.ac.uk (HELO mail.dcs.qmul.ac.uk) ([138.37.95.139]) by mail4-smtp-sop.national.inria.fr with ESMTP; 19 May 2008 13:46:36 +0200 Received: from 78-86-170-85.zone2.bethere.co.uk ([78.86.170.85] helo=xila.config) by mail.dcs.qmul.ac.uk with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Jy3p4-0004nh-9X for caml-list@inria.fr; Mon, 19 May 2008 12:46:35 +0100 Message-ID: <4831686F.8010903@doc.ic.ac.uk> Date: Mon, 19 May 2008 12:45:51 +0100 From: Martin Berger User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: caml-list@inria.fr Subject: Re: [Caml-list] Re: Where's my non-classical shared memory concurrency technology? References: <200805181735.50621.jon@ffconsultancy.com> In-Reply-To: <200805181735.50621.jon@ffconsultancy.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-DCS-Interface-Port: 465 X-DCS-Auth-User: martinb (person) X-Miltered: at discorde with ID 4831689D.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; fairness:01 non-trivial:01 parallelism:01 bread:98 threads:01 wrote:01 caml-list:01 data:02 face:97 slightly:03 bugs:03 bugs:03 programming:03 library:03 library:03 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, rather than relying on a tried and tested library, i.e. you have an additional source of bugs, without removing the problems that are inherent in concurrency (e.g. deadlocks, livelocks, fairness ...). There are reasons why writing your own concurrency mechanisms might be the way to go, but it's a highly non-trivial endeavor. 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. > 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