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 discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id 6D03CBC50 for ; Fri, 15 Sep 2006 22:21:11 +0200 (CEST) Received: from mailx.valdosta.edu (mailx.valdosta.edu [168.18.130.251]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id k8FKL921015721 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 15 Sep 2006 22:21:10 +0200 Received: from blazemail.valdosta.edu (blazemail.valdosta.edu [168.18.130.208]) by mailx.valdosta.edu (8.13.6/8.13.6) with ESMTP id k8FKL9Bv002745 for ; Fri, 15 Sep 2006 16:21:09 -0400 (EDT) (envelope-from jtbryant@valdosta.edu) Received: from [10.0.10.129] (bluemoon.valdosta.edu [168.18.147.67]) by blazemail.valdosta.edu (iPlanet Messaging Server 5.2 HotFix 2.04 (built Feb 8 2005)) with ESMTP id <0J5N005G2HV9CF@blazemail.valdosta.edu> for caml-list@yquem.inria.fr; Fri, 15 Sep 2006 16:21:09 -0400 (EDT) Date: Fri, 15 Sep 2006 16:19:15 -0400 From: Jonathan Bryant Subject: Concurrent GC To: caml-list@yquem.inria.fr Message-id: <0A61CB3F-0A3C-4157-A499-30AE860E8FF0@valdosta.edu> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.2) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.3.0.1, Antispam-Data: 2006.9.15.125943 X-Miltered: at discorde with ID 450B0B35.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; run-time:01 threads:01 ocaml:01 mutexes:01 ocaml:01 trivial:01 recursion:01 recursion:01 parallelism:01 mutexes:01 threads:01 abstractions:01 abstractions:01 recursively:01 slight:01 Apologies if this was sent out a few times: my email client and I are not getting along at the moment... :-\ My two cents, > It's very nice to have a concurrent run-time system, and we know how > to do it (at significant cost), but it's not really worth the trouble > until we have an answer to this question: what programming language > features do we put on top of it? > > Shared memory with threads, locks, and conditions just doesn't cut > it, in terms of writing programs that work. > For writing shared memory concurrent programs in OCaml, the Event module is a far better fit than locks, mutexes and conditions (oh, my!). It fits the functional paradigm much better and makes program design far easier to reason about. Even simple programs can benefit (design wise) from its use. One of the major advantages is that it's defined the same way as most of the other major types in the language (lists, sets, etc.): recursively, so it flows natrually from the language. For example, in C/C++/Java (shared memory concurrency), an algorithm such as merge sort is tricky, and parallelizing it is downright nasty, but in OCaml with the Event module (message passing concurrency), merge sort borders on trivial, and parallelizing it is almost as simple because the recursion of the algorithm and the recursion of the parallelism go hand in hand. Try it and you'll see. Mutexes, conditions, and locks really only need to be there for transliterating sequential, array based parallel code, but if you are doing that, the question really is why? OCaml outperforms C pretty much everywhere but that, and the true benefits of OCaml in this situation (cleanliness, safety, readability, etc.) are much better exploited by rethinking the algorithm using message passing. I feel that the (possible) slight hit in speed is completely justified by the numerous other benefits of the Event module. > I understand where you're coming from, but this point of view > implies, I think, an inappropriate division of labor between > language designers and language users. I agree, ordinary shared- > state concurrency with threads is a disaster. But the burden of > figuring out how to write concurrent programs in a reasonable way > is not just the responsibility of the language designer --- library > writers can come up with good abstractions to take advantage of > threads as well. > Again, great abstractions to take advantage of these multi-cored processors is already in the OCaml standard library: the Event module. All that we need is the ability to actually take advantage of it. > ...threads with real concurrency. Right now, ocaml doesn't provide > that, and it's a real weakness of the language. The lack of a > concurrent GC, in my opinion, stifles innovation in this area... > Agreed. --Jonathan Bryant