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 E5A97BB83 for ; Fri, 18 Aug 2006 17:14:37 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id k7IFEFG0016075 for ; Fri, 18 Aug 2006 17:14:37 +0200 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id RAA17773 for ; Fri, 18 Aug 2006 17:04:50 +0200 (MET DST) Received: from [128.93.11.95] (estephe.inria.fr [128.93.11.95]) by nez-perce.inria.fr (8.13.6/8.13.6) with ESMTP id k7HBtoPK027794; Thu, 17 Aug 2006 13:55:50 +0200 Message-ID: <44E45946.3090102@inria.fr> Date: Thu, 17 Aug 2006 13:55:50 +0200 From: Xavier Leroy User-Agent: Mozilla Thunderbird 1.0.6-6mdk (X11/20050322) X-Accept-Language: en-us, en MIME-Version: 1.0 To: malc Cc: Caml List Subject: Re: [Caml-list] Usage of condition variables References: In-Reply-To: X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 44E5D947.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; ocaml:01 threads:01 threads:01 posix:01 caml-list:01 variant:02 linuxthreads:02 linuxthreads:02 slightly:02 variables:02 variables:02 programming:03 seems:03 mutex:03 naive:03 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=DATE_IN_PAST_24_48 autolearn=disabled version=3.0.3 > [Use of condition variables] > However it seems like members of OCaml team strongly prefer unlock > then signal pattern. Given that Xavier Leroy is also the author of > LinuxThreads there might be some good arguments to have it that way, > or maybe it's because of vmthreads, perhaps someone could give the > rationale? That's an old debate -- I've seen threads of 100+ messages on this topic back in the days when I read comp.programming.threads. My take on this is that both patterns are correct if your program is reasonable, i.e. no real-time scheduling with priorities, and all uses of Condition.wait are protected against spurious wakeups (as they should always be). Moreover, the "unlock then signal" variant is slightly more efficient with naive thread implementations such as LinuxThreads, because "signal then unlock" can cause threads waiting on the condition to be restarted only to block immediately on the mutex. (More sophisticated implementations can avoid this by clever manipulations of wait queues.) Butenhof's book on POSIX threads probably contains a better discussion of the issue. - Xavier Leroy