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 43CA1BB81 for ; Thu, 9 Mar 2006 10:18:41 +0100 (CET) Received: from mail.davidb.org (mail.davidb.org [66.93.32.219]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id k299Ids3009452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 9 Mar 2006 10:18:40 +0100 Received: from davidb by mail.davidb.org with local (Exim 4.54 #1 (Debian)) id 1FHHI3-0002jI-Dk; Thu, 09 Mar 2006 01:18:35 -0800 Date: Thu, 9 Mar 2006 01:18:35 -0800 From: David Brown To: Andrae Muys Cc: Gerd Stolpmann , Brian Hurt , caml-list@yquem.inria.fr, William Lovas , skaller Subject: Re: [Caml-list] STM support in OCaml Message-ID: <20060309091835.GA9762@old.davidb.org> References: <440DB255.1030701@asfandyar.cjb.net> <1141751708.20944.355.camel@budgie.wigram> <440DD982.8080800@asfandyar.cjb.net> <1141779125.20944.405.camel@budgie.wigram> <20060308193633.GA5460@coruscant.stwing.upenn.edu> <1141855594.23909.63.camel@budgie.wigram> <1141855850.10771.100.camel@localhost.localdomain> <03CA5DC7-2934-42E0-A3A1-2D77F241F5D0@internode.on.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <03CA5DC7-2934-42E0-A3A1-2D77F241F5D0@internode.on.net> User-Agent: Mutt/1.5.11 X-Miltered: at nez-perce with ID 440FF2EF.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; ocaml:01 afaik:01 interprocess:01 posix:01 interprocess:01 mutexes:01 mutexes:01 end-up:01 cygwin:01 2006:98 hose:98 wrote:01 caml-list:01 caml-list:01 structures:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=SPF_SOFTFAIL autolearn=disabled version=3.0.3 On Thu, Mar 09, 2006 at 05:45:10PM +1000, Andrae Muys wrote: > >>I have no idea if Linux, for example, running SMP kernel, > >>is smart enough to know if a mutex is shared between two > >>processing units or not: AFAIK Linux doesn't support > >>interprocess mutex. Windows does. Be interesting to > >>compare. > > > >Of course POSIX supports interprocess mutexes: Mutexes are inherited > >across fork(). > > As skeller suggested, I can confirm this does not work. Mutexes are > not OS resources, they are initialised regions of memory (generally a > word). As fork() does copy-on-write, this leads to the mutex being > duplicated NOT shared; and yes given that fork() only duplicates the > calling thread, that does mean you can end-up with mutexes locked in > the child with no controlling thread available to unlock them. The mutex gets duplicated, including the data structures that indicate the process ids of who might have been waiting for it. fork() is an outstanding way to very thorougly hose an pthread application. Windows has the "advantage" of just not having fork. Well, not exactly, since Cygwin demonstrates that it can be faked. The Linux mutex code does use kernel scheduling resources (to go to sleep and signal each other), but the initial tests are done through the shared memory. Dave