A mutex for inter-process ;-)

[Daniel Eischen]

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