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,HTML_MESSAGE 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 9A082BB84 for ; Sun, 18 May 2008 10:39:18 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnADAHqIL0jRVcbudGdsb2JhbACCNzaPSQEMAwQGBw+UEoRr X-IronPort-AV: E=Sophos;i="4.27,503,1204498800"; d="scan'208";a="12388197" Received: from discorde.inria.fr ([192.93.2.38]) by mail1-smtp-roc.national.inria.fr with ESMTP; 18 May 2008 10:39:18 +0200 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id m4I8dIVf006620 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Sun, 18 May 2008 10:39:18 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnADAHqIL0jRVcbudGdsb2JhbACCNzaPSQEMAwQGBw+UEoRr X-IronPort-AV: E=Sophos;i="4.27,503,1204498800"; d="scan'208";a="12388195" Received: from rv-out-0506.google.com ([209.85.198.238]) by mail1-smtp-roc.national.inria.fr with ESMTP; 18 May 2008 10:39:17 +0200 Received: by rv-out-0506.google.com with SMTP id k40so700416rvb.57 for ; Sun, 18 May 2008 01:39:15 -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:mime-version:content-type; bh=8kCv4Tq/hzaJ/wUrWB6cqTTl6xjn2Yps27/vUU+4WS0=; b=akyy2pBfNTWtI7lP5A48OOj4t8migkfF9WEcS6gxts9pJS0M9S2jpY3DvPKk5klCqUchuGTucAORLCoMb7sOooYFvChekgpHJTsMwQSuV3Uxa76jg6xOzfMqbt5+CkewajEH64FPwGzXgf25NelxBnW/kCw4UM4eSB0+gXbHwlI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type; b=A6uANS7Aeba7VyXv0rB4yf4e8+z8J5UX5HHv5FVGIAHf2+jrObiZTib1QJXkP277hWHNud+D7mieoMplUUBtYiYw9LAN9XNI7ZbPQtorfMpM99AflHq0nqRJVUYMT/oN9+77CKG9QIcUIfP8ZJrVfZ+gUZo7Pwg3Uec53PE8lfU= Received: by 10.141.15.19 with SMTP id s19mr2895784rvi.269.1211099955754; Sun, 18 May 2008 01:39:15 -0700 (PDT) Received: by 10.140.172.2 with HTTP; Sun, 18 May 2008 01:39:15 -0700 (PDT) Message-ID: Date: Sun, 18 May 2008 10:39:15 +0200 From: "Berke Durak" To: "Jon Harrop" Subject: Where's my non-classical shared memory concurrency technology? Cc: caml-list MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_11259_17677139.1211099955763" X-Miltered: at discorde with ID 482FEB36.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; berke:01 durak:01 berke:01 durak:01 malloc:01 ml-like:01 malloc:01 ml-like:01 threads:01 threads:01 wrote:01 wrote:01 stack:01 stack:01 avoids:01 X-Attachments: cset="UTF-8" cset="UTF-8" ------=_Part_11259_17677139.1211099955763 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 - while reducing the concurrency capabilities. So it's not really improvement of safety, but rather avoidance of unsafety - a purely semantic issue. 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? -- Berke ------=_Part_11259_17677139.1211099955763 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Sun, May 18, 2008 at 12:03 AM, Jon Harrop <jon@ffconsultancy.com> 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 - while reducing the concurrency capabilities.  So it's not really improvement of safety, but rather avoidance of unsafety - a purely semantic issue.

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?
--
Berke

------=_Part_11259_17677139.1211099955763--