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 nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id C9224BB83 for ; Fri, 18 Aug 2006 05:14:53 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.6/8.13.6) with ESMTP id k7I3EE3T009803 for ; Fri, 18 Aug 2006 05:14:53 +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 VAA31802 for ; Thu, 17 Aug 2006 21:02:23 +0200 (MET DST) Received: from ash25e.internode.on.net (ash25e.internode.on.net [203.16.214.182]) by nez-perce.inria.fr (8.13.6/8.13.6) with ESMTP id k7H7fAqX000877 for ; Thu, 17 Aug 2006 09:41:15 +0200 Received: from rosella (ppp43-228.lns2.syd6.internode.on.net [59.167.43.228]) by ash25e.internode.on.net (8.13.6/8.13.5) with ESMTP id k7H7f0f2004518; Thu, 17 Aug 2006 17:11:02 +0930 (CST) (envelope-from skaller@users.sourceforge.net) Subject: Re: [Caml-list] Usage of condition variables From: skaller To: malc Cc: Caml List In-Reply-To: References: Content-Type: text/plain Date: Thu, 17 Aug 2006 17:41:00 +1000 Message-Id: <1155800460.5852.27.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; malc:01 threads:01 timedwait:01 predictable:01 ocaml:01 predictable:01 2006:98 sourceforge:01 wrote:01 caml-list:01 functions:01 cond:02 cond:02 variables:02 seems: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.0 required=5.0 tests=none autolearn=disabled version=3.0.3 On Thu, 2006-08-17 at 08:05 +0400, malc wrote: > > The pthread_cond_broadcast() or pthread_cond_signal() functions may be > called by a thread whether or not it currently owns the mutex that threads > calling pthread_cond_wait() or pthread_cond_timedwait() have associated > with the condition variable during their waits; however, if predictable > scheduling behavior is required, then that mutex shall be locked by the > thread calling pthread_cond_broadcast() or pthread_cond_signal(). > > > However it seems like members of OCaml team strongly prefer unlock > then signal pattern. When something is predictable, there is often a loss of efficiency compared to a more indeterminate option. In this case I'd guess that mutex lock/unlock triggers a scheduling operation because synchronisation is required anyhow. If there are multiple signallers it may be more efficient to delay long enough for the signals to be collated, and fire off the condition check only once. -- John Skaller Felix, successor to C++: http://felix.sf.net