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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 0A50CBBC1 for ; Tue, 22 Apr 2008 01:13:29 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AscAAFq8DEjUnw7Vb2dsb2JhbACCL48kAQwFAgUHGJkK X-IronPort-AV: E=Sophos;i="4.25,691,1199660400"; d="scan'208";a="9868495" Received: from ptb-relay02.plus.net ([212.159.14.213]) by mail2-smtp-roc.national.inria.fr with ESMTP; 22 Apr 2008 01:13:28 +0200 Received: from [80.229.56.224] (helo=beast.local) by ptb-relay02.plus.net with esmtp (Exim) id 1Jo5CR-000313-SG for caml-list@yquem.inria.fr; Tue, 22 Apr 2008 00:13:28 +0100 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] The closing gap (warning: long, inflammatory rant) Date: Tue, 22 Apr 2008 00:06:27 +0100 User-Agent: KMail/1.9.9 References: <480D01E4.5060207@lix.polytechnique.fr> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200804220006.27768.jon@ffconsultancy.com> X-Plusnet-Relay: 630063e1edb7a76b23e8d3d91e6069d8 X-Spam: no; 0.00; berke:01 durak:01 threading:01 model:01 mutable:01 malloc:01 malloc:01 abstraction:01 mutation:01 dependencies:01 mutation:01 kloc:01 dependencies:01 trivial:01 frog:98 On Monday 21 April 2008 22:16:49 Berke Durak wrote: > That's the point. The conventional threading model (mutable shared data > and mutexland) is unsafe by default. It's like the good old days of manual > memory management in C, except that you replace malloc/free with > pthread_mutex_lock/pthread_mutex_unlock and signal 11 by deadlocks. That is not "unsafe" in the conventional sense but it is a potential problem. The severity is due to difficulty of debugging (which .NET and Visual Studio actually handle extremely well) rather than this being a common problem. > But it's actually worse because mutexing doesn't compose as well as malloc. > This means that it's difficult to increase the abstraction level. I disagree. Locks are a problem in mainstream software because mutation is everywhere so many locks are required and the rats nest of dependencies is unmaintainable. However, this is not the case in functional languages where mutation is only found in performance-critical sections. Our 250kLOC visualization code base required only 4 locks in the entire library to parallelize it. Maintaining the dependencies between these locks is trivial on the scale of things. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e