A mutex for inter-process ;-)

Daniel Eischen deischen at freebsd.org
Mon Mar 30 16:56:13 PDT 2009


On Mon, 30 Mar 2009, Randall Stewart wrote:

>
> On Mar 30, 2009, at 5:22 PM, Daniel Eischen wrote:
>
>> On Mon, 30 Mar 2009, Randall Stewart wrote:
>> 
>>> Hi all:
>>> 
>>> I have recently written a small set of routines that allow
>>> two process to have a "mutex" between them.. actually it allows
>>> all of the threads in any set of processes to have mutexes between 
>>> themselves ;-)
>>> 
>>> Anyway it seems to be working fairly well.. I still have to write a man 
>>> page
>>> for it (documentation always last).. and eventually I would like to port 
>>> in
>>> some of the WITNESS type features since the mutex's have names..
>>> 
>>> I probably should also think about scaling it up a bit.. right now its 
>>> really
>>> more for a small scale (100 or less mutexes)...
>>> 
>>> Who should I talk to about getting this in... having it reviewed etc. I 
>>> think
>>> it belongs in libthr since it really needs the tid of the pthreads from 
>>> the
>>> pthread_t type... and for now I have a horrible hack in to get it ;-)
>> 
>> The real way to do this is to support PTHREAD_PROCESS_SHARED
>> mutexes within our normal mutex, and to change our current
>> mutex (and cv) types to be structs instead of pointers.
>> The current API, other than the type change, shouldn't
>> change at all.
>
>
> So how do you propose to name the mutex's so that two disparate
> process can locate the same mutex?

They are placed in shared memory, according to POSIX.

> I don't see how a pthread_mutex can suffice... we need more than
> just the current mutex...
>
> 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

-- 
DE


More information about the freebsd-threads mailing list