From owner-freebsd-threads@FreeBSD.ORG Tue Mar 31 07:01:38 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 76D41106564A for ; Tue, 31 Mar 2009 07:01:38 +0000 (UTC) (envelope-from eischen@vigrid.com) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 432898FC28 for ; Tue, 31 Mar 2009 07:01:38 +0000 (UTC) (envelope-from eischen@vigrid.com) 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 n2V6oRV7019827; Tue, 31 Mar 2009 02:50:27 -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]); Tue, 31 Mar 2009 02:50:27 -0400 (EDT) Date: Tue, 31 Mar 2009 02:50:27 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Randall Stewart In-Reply-To: <9157F968-5CCF-451C-9BA0-E12A957D6B38@lakerest.net> Message-ID: References: <7D4F6788-0F12-4863-9635-7FADA9115D16@lakerest.net> <9157F968-5CCF-451C-9BA0-E12A957D6B38@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 List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 07:01:38 -0000 On Tue, 31 Mar 2009, Randall Stewart wrote: > Daniel: > > In-line :-) > > > On Mar 30, 2009, at 7:56 PM, Daniel Eischen wrote: > >> On Mon, 30 Mar 2009, Randall Stewart wrote: >> >>> >>> What am I missing? >> >> As far as I know, David Xu implemented the kernel hooks >> for umtx (the underlying mutex in pthread mutex) to be >> shared. As soon as you can place the entire userland >> pthread_mutex_t struct in shared memory, it should all >> just work (with probably some trivial changes in libthr). >> The harder part is versioning all the symbols that >> currently think pthread_mutex_t, pthread_cond_t, etc, >> are pointers, and defining the structs with enough >> foresight so that it is unlikely we have to modify >> them in the future (causing a future ABI breakage), >> and also aligning them nicely for the various archs. >> >> You should really look at how POSIX defines process >> shared mutex, cvs, etc. See: >> >> pthread_barrierattr_[gs]etpshared() >> pthread_condattr_[gs]etpshared() >> pthread_mutexattr_[gs]etpshared() >> pthread_wrlockattr_[gs]etsphared() >> >> You can use this as a starting point: >> >> http://www.opengroup.org/onlinepubs/009695399/ >> http://www.opengroup.org/onlinepubs/009695399/functions/pthread_barrierattr_setpshared.html >> http://www.opengroup.org/onlinepubs/009695399/functions/pthread_condattr_setpshared.html >> http://www.opengroup.org/onlinepubs/009695399/functions/pthread_mutexattr_setpshared.html >> http://www.opengroup.org/onlinepubs/009695399/functions/pthread_rwlockattr_setpshared.html > > Ok, I have poked around at these... all the mutex attributes defined here > do is set the attributes to shared. There does not seem to be any standard > naming mechanism. Naming mechanism for what? Names shouldn't be needed for anything, nor do I think it is desired. > In fact following the set attributes stuff it gives examples of a condition > variable and defines "new local methods" to get a shared semaphore. Creating > the actual naming semantics in the new local methods. All that they > do on the mutex side is set the attributes to "shared" and basically do > the very same thing that I was playing with... i.e. mmap() the file > after initializing it... They define the API. We should not be making new APIs for something that already exists, that applications already know how to use, etc. > Now granted I did not use the pthread_mutex_*() calls themselves but instead > used the umtx() calls directly on the shared memory. Not sure if there is > much difference there.. but in any event there is no declaration here > in posix on calls for setting "names" so one could then expand the stuff > and add witness etc. It looks to me like its more or less a "left open" > for future work.. See above. The proper way to do this is to define the pthread_foo types, mark them as pshared, and have libthr make appropriate umtx calls when they are marked as shared. It is up to the application to define the shared memory segment and place the pthread types in the shared memory. There is no need for "names" on umtx, mutex, whatever. The kernel umtx, as David already pointed out, already handles process shared umtx. -- DE