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 7206BBB83 for ; Thu, 17 Aug 2006 06:05:39 +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 k7H45dat015884 for ; Thu, 17 Aug 2006 06:05:39 +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 GAA25831 for ; Thu, 17 Aug 2006 06:05:38 +0200 (MET DST) Received: from comtv.ru (vmail.comtv.ru [217.10.32.17]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id k7H45c5o027292 for ; Thu, 17 Aug 2006 06:05:38 +0200 X-UCL: actv Received: from av1474.oops ([10.0.66.9] verified) by comtv.ru (CommuniGate Pro SMTP 4.1.8) with ESMTP id 164487506 for caml-list@inria.fr; Thu, 17 Aug 2006 08:05:33 +0400 Date: Thu, 17 Aug 2006 08:05:30 +0400 (MSD) From: malc X-X-Sender: malc@home.oyster.ru To: Caml List Subject: Usage of condition variables Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Miltered: at concorde with ID 44E3EB12.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; malc:01 malc:01 pulsesoft:01 unix:01 unix:01 opengroup:01 onlinepubs:01 threads:01 timedwait:01 predictable:01 ocaml:01 pulsesoft:01 functions:01 functions:01 linuxthreads:02 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=FORGED_RCVD_HELO autolearn=disabled version=3.0.3 Hello, Recently in the process of discussing one problem i was having subject temporarily switched to the condition variables: http://groups.google.com/group/comp.unix.programmer/tree/browse_frm/thread/5394d00781547266/17c8a349edae9d3c?rnum=1_done=%2Fgroup%2Fcomp.unix.programmer%2Fbrowse_frm%2Fthread%2F5394d00781547266%2F17c8a349edae9d3c%3Ftvc%3D1%26q%3Dmalc%26#doc_b586db199a5fd81a Also according to: http://www.opengroup.org/onlinepubs/009695399/functions/pthread_cond_signal.html 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. 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? So far only this: http://groups.google.com/group/comp.unix.programmer/msg/02751100d1b953e3 was in favour of unlock then signal. -- mailto:malc@pulsesoft.com