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 C51B5BB81 for ; Thu, 9 Mar 2006 08:45:21 +0100 (CET) Received: from ns1.softwarememetics.com (ns1.tucanatech.com [205.177.124.123]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id k297jK7I027791 for ; Thu, 9 Mar 2006 08:45:21 +0100 Received: from [192.168.31.18] (unknown [203.144.27.9]) by ns1.softwarememetics.com (Postfix) with ESMTP id 2878232C97; Thu, 9 Mar 2006 03:17:23 -0500 (EST) In-Reply-To: <1141855850.10771.100.camel@localhost.localdomain> 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> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <03CA5DC7-2934-42E0-A3A1-2D77F241F5D0@internode.on.net> Cc: skaller , Brian Hurt , caml-list@yquem.inria.fr, William Lovas Content-Transfer-Encoding: 7bit From: Andrae Muys Subject: Re: [Caml-list] STM support in OCaml Date: Thu, 9 Mar 2006 17:45:10 +1000 To: Gerd Stolpmann X-Mailer: Apple Mail (2.746.2) X-Miltered: at concorde with ID 440FDD10.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; ocaml:01 gerd:01 stolpmann:01 donnerstag:01 posix:01 afaik:01 interprocess:01 posix:01 interprocess:01 mutexes:01 mutexes:01 end-up:01 threads:01 implements:01 threads: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.9 required=5.0 tests=FORGED_RCVD_HELO,SPF_SOFTFAIL autolearn=disabled version=3.0.3 On 09/03/2006, at 8:10 AM, Gerd Stolpmann wrote: > Am Donnerstag, den 09.03.2006, 09:06 +1100 schrieb skaller: >> On Wed, 2006-03-08 at 14:45 -0600, Brian Hurt wrote: >> >>> One comment I will make is that a mutex is expensive, but not *that* >>> expensive. I just wrote a quick program (available if anyone >>> cares) in >>> GNU C that measures the cost, in clocks, of locking and unlocking >>> a posix >>> mutex. On my desktop box (AMD Athlon XP 2200+ 1.8GHz), I'm >>> getting a cost >>> of like 44 clock cycles. Which makes it less expensive than an >>> L2 cache >>> miss. > >> 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. fork() safety is an important issue to be aware of when working with posix-threads. The best reference I am familiar with is Programming With Threads by Kleiman, Shah, and Smaalders, which includes a whole chapter on the this and related topics. > And Linux even implements threads as processes, so you > can even place mutexes in shared memory (but do not ask me how). I've done this in an embedded app I wrote a few years back. It's not hard, you create the shared-memory segment, cast some of it to be of type pthread_mutex_t and pass it to pthread_mutex_init() (I'm working from memory here, so the function/type names may be off). > Anyway, measuring the costs of a mutex is probably not simple. They > are > highly optimized for the frequently occurring cases. And today "SMP" > behaves often more like NUMA, especially for multi-core CPUs. Agreed, however in my experience, if optimistic locking isn't going to work for you then neither are mutex-based shared-memory approaches. Andrae Muys -- Andrae Muys andrae@netymon.com Principal Kowari Consultant Netymon Pty Ltd