From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 2E3FBBB81 for ; Tue, 27 Sep 2005 18:10:57 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j8RGAuhY008816 for ; Tue, 27 Sep 2005 18:10:56 +0200 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id SAA31502 for ; Tue, 27 Sep 2005 18:10:56 +0200 (MET DST) Received: from conn.mc.mpls.visi.com (conn.mc.mpls.visi.com [208.42.156.2]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j8RGAtiv008803 for ; Tue, 27 Sep 2005 18:10:55 +0200 Received: from [192.168.42.2] (bhurt.dsl.visi.com [208.42.141.66]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id 2604F81EF; Tue, 27 Sep 2005 11:10:51 -0500 (CDT) Date: Tue, 27 Sep 2005 11:11:16 -0500 (CDT) From: Brian Hurt X-X-Sender: bhurt@localhost.localdomain To: Stefan Monnier Cc: skaller , caml-list Subject: Re: [Caml-list] Re: Ant: Efficiency of let/and In-Reply-To: Message-ID: References: <20050926043240.24009.qmail@web26809.mail.ukl.yahoo.com> <87hdc724wo.fsf-monnier+gmane.comp.lang.caml.inria@gnu.org> <1127800374.31518.167.camel@rosella> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Miltered: at concorde with ID 43396F10.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 43396F0F.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 trivial:01 threads:01 threads:01 garbage:01 2005,:98 wrote:01 imho:01 let:03 brian:03 brian:03 100%:94 problem:05 problem:05 sep:05 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 On Tue, 27 Sep 2005, Stefan Monnier wrote: >> chips, etc.). The problem is that the theory on how to write race >> condition/deadlock/livelock -free code isn't there, to my knowledge > > I think the theory is pretty much there. The problem is to put it > into practice. I'm not 100% sure it is. Oh, it is for the "trivial" questions- like will this program run to completion and will it return the right answer? But it isn't there yet (to my knowledge) on the more difficult questions, like can I automatically tune this program to efficiently use N threads (where both N=1 and N ~ millions are interesting values)? And what is the minimum amount of synchronization this program requires at N threads? Etc. IMHO, we need to take synchronization out of the hands of the programmer just like we took garbage collection out of the hands of the programmer. But, then again, I'm widely regarded as a radical :-). Brian