From owner-freebsd-threads@FreeBSD.ORG Sun Apr 12 19:23:53 2009 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07A2810656BD for ; Sun, 12 Apr 2009 19:23:53 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 98ACF8FC1F for ; Sun, 12 Apr 2009 19:23:52 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id n3CJNpmH022338; Sun, 12 Apr 2009 15:23:51 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Sun, 12 Apr 2009 15:23:51 -0400 (EDT) Date: Sun, 12 Apr 2009 15:23:51 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Randall Stewart In-Reply-To: Message-ID: References: <7D4F6788-0F12-4863-9635-7FADA9115D16@lakerest.net> <9157F968-5CCF-451C-9BA0-E12A957D6B38@lakerest.net> <081E4C0E-4DD0-45DA-BDFE-89FC2388E1AE@lakerest.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: threads@freebsd.org Subject: Re: A mutex for inter-process ;-) X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 19:23:53 -0000 On Wed, 8 Apr 2009, Randall Stewart wrote: > Daniel: > > Ok due to working on a sun benchmark (libMicro) I have > came back to this again :-) > > Turns our our friends at sun in their benchmark arrange for > threads in separate process, all started by the same parent > process, to collaborate by using pthread_mutex and pthread_cond > variables. These are allocated in the main process and mmap()'d into > shared memory. Of course none of this works at all in FreeBSD. > > The reason being that both the pthread_mutex_init and pthread_cond_init > under the covers allocate memory for the real pthread_mutex or pthread_cond > structure.. not the pointer the user hangs on to. So sun's benchmarks > all hang if multiple process are involved since they all go to wait > on a local condition variable ;-) > > I suppose in Sun's Solaris the pthread_mutex structure is the entire > structure so that when they mmap it they get it all in shm... > > So, what really needs to be done here is we rework the > pthread_cond/mutex to allowed the shared attribute that they are > setting (yes they do this) to actually do something. Of course just > being aware of the issue does not solve the problem.. since you really > need to NOT malloc inside the cond/mutex init code to make this work.. and > instead make the "private" structures setup so the user can malloc these. Please see my original reply to this: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=12714+0+archive/2009/freebsd-threads/20090405.freebsd-threads "... and to change our current mutex (and cv) types to be structs instead of pointers." -- DE