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=2.8 required=5.0 tests=DNS_FROM_RFC_POST,SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id A6BBEBBC4; Sat, 21 Feb 2009 00:40:13 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArMBAKfNnknRVcbkkGdsb2JhbACUGD8BAQEBCQkMBxEDriaBBY84AQMBA4QMBoJT X-IronPort-AV: E=Sophos;i="4.38,244,1233529200"; d="scan'208";a="23305800" Received: from rv-out-0506.google.com ([209.85.198.228]) by mail3-smtp-sop.national.inria.fr with ESMTP; 21 Feb 2009 00:40:12 +0100 Received: by rv-out-0506.google.com with SMTP id k40so10212039rvb.57 for ; Fri, 20 Feb 2009 15:40:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:cc:x-mailer; bh=WU3gir3D2ao9gRyDBRD20g3VNEMgJVmPbcWifLU0U5Y=; b=GHdRBU284M4TEihvc1BejzPnOYgXNeIjz2hLMKI3nPZucCT9RhhzK1QhJBM74ZF0Nw TLLxi9B76hyF6AobcaBJpl6HHAjKZcdZa/ayPWcS63+eL95npaa+NIAvAEC2CKICjGaC BCgM6kDGNiKefGCL0Gviq3ZTTKJMCPXb3RFC4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:cc:x-mailer; b=SZeJ4cRs+JqSJbFzWQX96KWS/qRcV5eeCtC9sjkzaew9FFCU+FmmmznQ51+sJILcsQ Do2qvJno0KjAwl+DGqwaV/ZlOhhA28WwIkm3uZsL3wU2onxEG4gawrtJihb3Yx/wKD4p plEuDMQPR7fvNXcl5vXlr+Njt6fZ7ZmbS9LLE= Received: by 10.141.28.2 with SMTP id f2mr651290rvj.170.1235173211140; Fri, 20 Feb 2009 15:40:11 -0800 (PST) Received: from ?10.150.243.99? ([32.139.250.52]) by mx.google.com with ESMTPS id k2sm7099174rvb.4.2009.02.20.15.40.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 20 Feb 2009 15:40:09 -0800 (PST) References: <20090217155455.GA2352@stock.ovh.net> <891bd3390902171214s40e4c378sc9c373f6c2822597@mail.gmail.com> <499EF82C.6080101@inria.fr> Message-Id: <2EB5F7EC-3F7C-4302-B338-03EF6311D537@gmail.com> From: Yaron Minsky To: Xavier Leroy In-Reply-To: <499EF82C.6080101@inria.fr> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (iPhone Mail 5H11) Subject: Re: [Caml-list] Lazy and Threads Date: Fri, 20 Feb 2009 18:01:01 -0500 Cc: "victor-caml-list@nicollet.net" , "caml-list@inria.fr" X-Mailer: iPhone Mail (5H11) X-Spam: no; 0.00; yaron:01 minsky:01 yminsky:01 yaron:01 minsky:01 bug:01 mutexes:01 stdlib:01 buffered:01 buffered:01 complained:01 ocaml's:01 speedup:01 computations:01 granularity:01 You're totally right. I withdraw my complaint. y Yaron Minsky On Feb 20, 2009, at 1:36 PM, Xavier Leroy wrote: > Victor Nicollet wrote: >> I'm working with both lazy expressions and threads, and noticed >> that the >> evaluation of lazy expressions is not thread-safe: > > Yaron Minsky wrote: >> At a minimum, this seems like a bug in the documentation. The >> documentation states very clearly that Undefined is called when a >> value >> is recursively forced. Clearly, you get the same error when you >> force a >> lazy value that is in the process of being forced for the first >> time.... >> It does seem like fixing the behavior to match the current >> documentation >> would be superior to fixing the documentation to match the current >> behavior. > > It's not just the Lazy module: in general, the whole standard library > is not thread-safe. Probably that should be stated in the > documentation for the threads library, but there isn't much point in > documenting it per standard library module. > > As to making the standard library thread-safe by sprinkling it with > mutexes, Java-style: no way. There is one part of the stdlib that is > made thread-safe this way: buffered I/O operations. (The reason is > that, owing to the C implementation of some of these operations, a > race condition in buffered I/O could actually crash the whole program, > rather than just result in unexpected results as in the case of pure > Caml modules.) You (Yaron) and others recently complained that such > locking around buffered I/O made some operations too slow for your > taste. Wait until you wrap a mutex around all Lazy.force > operations... > > More generally speaking, locking within a standard library is the > wrong thing to do: that doesn't prevent race conditions at the > application level, and for reasonable performance you need to lock at > a much coarser grain, again at the application level. (That's one of > the things that make shared-memory programming with threads and locks > so incredibly painful and non-modular.) > > Coming back to Victor's original question: > >> Aside from handling a mutex myself (which I don't find very >> elegant for >> a read operation in a pure functional program) is there a >> solution I can >> use to manipulate lazy expressions in a pure functional multi- >> threaded >> program? > > You need to think more / tell us more about what you're trying to > achieve with sharing lazy values between threads. > > If your program is really purely functional (i.e. no I/O of any kind), > OCaml's multithreading is essentially useless, as you're not going to > get any speedup from it and would be better off with sequential > computations. If your program does use threads to overlap computation > and I/O, using threads might be warranted, but then what is the > appropriate granularity of locking that you'd need? > > A somewhat related question is: what semantics do you expect from > concurrent Lazy.force operations on a shared suspension? One thread > blocks while the other completes the computation? Same but with busy > waiting? (if the computations are generally small). Or do you want > speculative execution? (Both threads may evaluate the suspended > computation.) > > There is no unique answer to these questions: it all depends on what > you're trying to achieve... > > - Xavier Leroy