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 mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 06900BB84 for ; Tue, 20 May 2008 00:24:22 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkMBAFabMUjAXQIniGdsb2JhbACSMgEBAQ8glyeEbg X-IronPort-AV: E=Sophos;i="4.27,511,1204498800"; d="scan'208";a="12459515" Received: from concorde.inria.fr ([192.93.2.39]) by mail1-smtp-roc.national.inria.fr with ESMTP; 20 May 2008 00:24:21 +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 m4JMOLP9030454 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Tue, 20 May 2008 00:24:21 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtkCAFabMUjRVcbtZGdsb2JhbACSJRoDBAQJEgKXJIRu X-IronPort-AV: E=Sophos;i="4.27,511,1204498800"; d="scan'208";a="10899060" Received: from rv-out-0506.google.com ([209.85.198.237]) by mail2-smtp-roc.national.inria.fr with ESMTP; 20 May 2008 00:24:15 +0200 Received: by rv-out-0506.google.com with SMTP id k40so1358811rvb.57 for ; Mon, 19 May 2008 15:24:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=YXgSj81p2SCzypz+7S+e6OHhLp206ACqd0LrCgDLAn4=; b=H0yBMIX8aWcRxugY2xvL8EmfNhsAa+3xRmURw7j1sfzWBmZHYp/kb/J6FNV2+cRmfM8pQZ+Hcu6F6fFK9QIvnFUXwFvYKIBqTmxUyMQvXm28YlELYK6UYm1y/pF988xrosj01qxemcpFnCPjm8/BfbpLOW8uWI1kbX15dI0MDcA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=AZ6eo4+k7H5XYd76sYBWEDPROhFpMOwImhuei5A0cplkCnPxJJVtohbqejtZzjhLoNs5MqNXFFZXY4E5XWHmVEC80rL4XgXLjSwJhNf8prZpKYue8FM1+pULLz7zXHL3nXuoFeyzCB20MP4lCeUCmZUlEPlIg4gdQQSpmzAIRnU= Received: by 10.140.133.9 with SMTP id g9mr3975266rvd.235.1211235854700; Mon, 19 May 2008 15:24:14 -0700 (PDT) Received: by 10.140.172.2 with HTTP; Mon, 19 May 2008 15:24:14 -0700 (PDT) Message-ID: Date: Tue, 20 May 2008 00:24:14 +0200 From: "Berke Durak" To: "Jon Harrop" Subject: Re: [Caml-list] Re: Where's my non-classical shared memory concurrency technology? Cc: caml-list In-Reply-To: <200805192247.09949.jon@ffconsultancy.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4831686F.8010903@doc.ic.ac.uk> <200805192247.09949.jon@ffconsultancy.com> X-Miltered: at concorde with ID 4831FE15.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; berke:01 durak:01 berke:01 durak:01 parallelism:01 parallelism:01 ocaml:01 event-driven:01 mutable:01 non-trivial:01 threads:01 threads:01 wrote:01 wrote:01 caml-list:01 On Mon, May 19, 2008 at 11:47 PM, Jon Harrop wrote: > > There are two problems with what you wrote in this context: > > 1. You are replying to a thread about shared-memory parallelism with a > discussion of sequential concurrency, which is completely different. > > 2. You keep saying "avoiding threads" but what you mean is "avoiding > parallelism". No, because Ocaml threads today avoid parallelism, but you can still get inconsistency bugs. You'd only get them faster with parallel execution :) > In essence, your solution to bugs that arise due to parallelism is to avoid > parallelism. While true, that is not going to help anyone exploit multicores. We're going in circles again. I was just arguing, again, that Thread.create + Mutex.lock = more bugs than event-driven execution. Now, yes, that doesn't heat all your cores, so that's why I changed the subject to "where is my shared-memory concurrency technology?" - not a rhetorical question, but a real one. So, my question is : Given that shared, mutable global state accessed with multiple threads is a recipe for bugs that no amount of data hiding can solve (because -locking-sections-don't-compose-), did anyone invent and implement a usable type or other system for making concurrency and parallelism safe? If the answer is STM, please show me some non-trivial application that uses it, preferably in an impure language. -- Berke Durak