What is the status of thread process-shared synchronization?

Daniel Eischen deischen at freebsd.org
Thu Feb 6 05:41:17 UTC 2014


On Thu, 6 Feb 2014, Luca Bayer wrote:

> John Baldwin <jhb at freebsd.org> writes:
>
>>> Hi folks!
>>>
>>> The FreeBSD 8.1 manual pages state that pthread process-shared
>>> synchronization option is not supported, at least for some primitives.
>>>
>>> 1) Are there any plans to implement this option?
>>> 2) Is anybody working on that?
>>> 3) What are the main obstacles which prevent us from having the option
>>> implemented?
>>>
>>> I am teaching students UNIX-like systems in general and FreeBSD in
>>> particular. I've set them a task on synchronizing processes reading
>>> and writing from a shared-memory cache. But then found that in spite
>>> of PTHREAD_PROCESS_SHARED being available, it is not supported. I've
>>> endeavored to fix POSIX rwlocks by making pthread_rwlock_t a
>>> structure, but then found that POSIX semaphores do not support
>>> process-shared attribute either.
>>
>> I believe POSIX semaphores in 9 do now support PTHREAD_PROCESS_SHARED.  David
>> Xu implemented it.  He may be able to MFC this to 8-stable.
>
> I wonder what's the status of process-shared mutexes. They still don't
> work as compared to glibc (linux and kfreebsd). Here's a failing example

[ ... ]

Process shared synchronization objects are not yet
supported because our POSIX synchronization object types
are pointers and are allocated by the process - they
can't be shared.

>> Unfortunately the various POSIX/SYSV primitives do not currently support it in
>> 8.  You could implement a shared mutex on top of umtx fairly easily I believe.
>> umtx itself is address-space agnostic (so a umtx object can be shared among
>> processes), and the existing pthread_mutex code can probably be borrowed
>> directly to implement a mutex.  I think the biggest obstacle for FreeBSD is
>> changing the definition of pthread_mutex_t, etc. to be structures instead of
>> pointers to dynamically allocated structures.

Yes, there are some ABI problems to be worked out if we
change our synchronization objects (at least mutex and
CVs) to structs.  David has some code that does this,
but we're not quite sure how to treat the ABI compatibility.

One problem is if an older compiled library (which views
and creates mutexes/CVs as pointers) passes a mutex/CV
to a newer compiled library or application that views the
mutex/CV as a struct.  We think we can solve this by
or'ing a 1 into the pointer returned from the compat
version of the foo_create() function.  Then we can
tell if the object is a pointer or not - ugly, but it
might work.  The other option is to bump library
versions - this is messy too, but we've done it before.

The other problem is that some code (looks like the
NVIDIA driver) doesn't link to libpthread and uses
dlsym() to get the address of pthread_mutex_create().
(to see if the calling application needs threading
support).  If not null, it then calls pthread_mutex_create()
by dereferencing the address.  This could return the
the pthread_mutex_create() that uses structs, but
the NVIDIA driver, if not rebuilt, would only allocate
a pointer for it.  I argue using dlsym() and friends
bypass any ABI compatibility and shouldn't really be
supported.  I don't think bumping library versions
would even solve this problem.

-- 
DE


More information about the freebsd-threads mailing list