From owner-freebsd-threads@FreeBSD.ORG Wed Apr 8 18:08:22 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 F30501065670; Wed, 8 Apr 2009 18:08:21 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by mx1.freebsd.org (Postfix) with ESMTP id 72F908FC1D; Wed, 8 Apr 2009 18:08:21 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from [10.1.1.54] ([10.1.1.54]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id n38I8JD9071358 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 8 Apr 2009 14:08:20 -0400 (EDT) (envelope-from rrs@lakerest.net) DKIM-Signature: a=rsa-sha1; c=simple/simple; d=lakerest.net; s=mail; t=1239214100; h=Cc:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:References: X-Mailer; b=TooVvEi6cN6S/igdWd9qLshdW57f1fWkz3Q7FvPZPMI4G+/2t0j/gTb arIEAON5Q0a9/pbF83PXnyKPZW3Xpnw== Message-Id: From: Randall Stewart To: Daniel Eischen In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 8 Apr 2009 14:08:19 -0400 References: <7D4F6788-0F12-4863-9635-7FADA9115D16@lakerest.net> <9157F968-5CCF-451C-9BA0-E12A957D6B38@lakerest.net> <081E4C0E-4DD0-45DA-BDFE-89FC2388E1AE@lakerest.net> X-Mailer: Apple Mail (2.930.3) 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 List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 18:08:22 -0000 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. I did notice that the underlying thr_ library allows one to pass in a allocator .. this might be useful except for it does not fit in the posix model. I am not sure how to proceed with this, since it would take some re-work in the thread library... I could do it but I am sure I would not do it the way y'all would like :-) So for now I am going to see about expanding my little toy library that uses umtx to include cond variables and then adapt the sun libMicro to use that so I can move forward with all of their benchmarks that do multi-process stuff :-) R ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct)