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=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id D058ABB84 for ; Sun, 18 May 2008 18:40:10 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswEAIL4L0jUnw7Vb2dsb2JhbACCM5ABAQwFAgQHE5hx X-IronPort-AV: E=Sophos;i="4.27,505,1204498800"; d="scan'208";a="26310650" Received: from concorde.inria.fr ([192.93.2.39]) by mail4-smtp-sop.national.inria.fr with ESMTP; 18 May 2008 18:40:10 +0200 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id m4IGe99p004849 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Sun, 18 May 2008 18:40:10 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswEAIL4L0jUnw7Vb2dsb2JhbACCM5ABAQwFAgQHE5hx X-IronPort-AV: E=Sophos;i="4.27,505,1204498800"; d="scan'208";a="26310647" Received: from ptb-relay02.plus.net ([212.159.14.213]) by mail4-smtp-sop.national.inria.fr with ESMTP; 18 May 2008 18:40:09 +0200 Received: from [80.229.56.224] (helo=beast.local) by ptb-relay02.plus.net with esmtp (Exim) id 1Jxlvc-0007yF-SR for caml-list@inria.fr; Sun, 18 May 2008 17:40:09 +0100 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list Subject: Re: Where's my non-classical shared memory concurrency technology? Date: Sun, 18 May 2008 17:35:50 +0100 User-Agent: KMail/1.9.9 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200805181735.50621.jon@ffconsultancy.com> X-Plusnet-Relay: 602c0e47f285eb4fc85c494034d2d176 X-Miltered: at concorde with ID 48305BEA.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; berke:01 durak:01 malloc:01 ml-like:01 parallelism:01 frog:98 threads:01 threads:01 wrote:01 wrote:01 stack:01 avoids:01 data:02 impractical:02 bugs:03 On Sunday 18 May 2008 09:39:15 Berke Durak wrote:> On Sun, May 18, 2008 at 12:03 AM, Jon Harrop wrote: > > Avoiding threads does not improve the safety of the language, it simply > > degrades the capabilities of the language. > > Avoiding threads is like avoiding malloc() in a C program and doing only > static and stack allocation: it is cumbersome and impractical, but avoids a > whole class of allocation bugs. > > Similarly, avoiding threads removes concurrency bugs... Are you sure? Can you not still have two agents mutually waiting on each other for a message (a deadlock) or messages not being ordered before consumption (a race condition)? I don't believe you have removed any concurrency bugs. I think you just pushed them around a bit. > I think we are still lacking programming language technology to integrate > safe and easy-to-use shared memory concurrency in ML-like languages. Does > anyone know of anything in this area aside from transactional memory? Data parallelism in Microsoft's Task Parallel Library. I have no use for STM myself. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e