Date: Tue, 31 Mar 2009 07:05:18 -0400 From: Randall Stewart <rrs@lakerest.net> To: Daniel Eischen <eischen@vigrid.com> Cc: threads@freebsd.org Subject: Re: A mutex for inter-process ;-) Message-ID: <081E4C0E-4DD0-45DA-BDFE-89FC2388E1AE@lakerest.net> In-Reply-To: <Pine.GSO.4.64.0903310235580.5671@sea.ntplx.net> References: <7D4F6788-0F12-4863-9635-7FADA9115D16@lakerest.net> <Pine.GSO.4.64.0903301719000.2318@sea.ntplx.net> <AC6F7359-28D5-4F92-93AF-43B6AF86FC01@lakerest.net> <Pine.GSO.4.64.0903301935300.2318@sea.ntplx.net> <9157F968-5CCF-451C-9BA0-E12A957D6B38@lakerest.net> <Pine.GSO.4.64.0903310235580.5671@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 31, 2009, at 2:50 AM, Daniel Eischen wrote: > 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. So what you are saying is ... just let the application do it. Provide nothing but the ability to "mark" a mutex as shared. And let the app figure it out. Hmm.. If one company is asking for this ability i.e. easily do shared mutexs I am sure other folks have wanted it as well. Now rolling your own is a valid thing to do.. but it seems to me providing something for general use is not a bad idea either. The pages you pointed out even show such a mechanism for semaphores... i.e. there definition of semaphore_create(char *shared_name) semaphore_open(char *shared_name) semaphore_post(..) and kin. Curious place for it though.. under pthread_mutex_destroy() ;-) And of course as pointed out this does not solve the quick death syndrome (for that matter neither did I yet but I am thinking about this one ;D)... which is the real hard problem.. and really does require assistance beyond what an application can generally do... IMO having a general library function available is a good thing. If you are not interested in seeing it in libthr where I think it would belong.. thats fine I can build a port or other such... I will send Julian the manual page after I get it built through :-D R > > >> 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 > > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?081E4C0E-4DD0-45DA-BDFE-89FC2388E1AE>