Date: Thu, 6 Feb 2014 00:39:13 -0500 (EST) From: Daniel Eischen <deischen@freebsd.org> To: Luca Bayer <kometto@web.de> Cc: Alexander Churanov <alexanderchuranov@gmail.com>, David Xu <davidxu@freebsd.org>, freebsd-threads@freebsd.org Subject: Re: What is the status of thread process-shared synchronization? Message-ID: <Pine.GSO.4.64.1402060007020.992@sea.ntplx.net> In-Reply-To: <20140206.86sirxgj8x@web.de> References: <AANLkTikXSKt0ysmLL7bU2H%2B9vqasmJktpfwwn5mOSSEH@mail.gmail.com> <201009231006.40019.jhb@freebsd.org> <20140206.86sirxgj8x@web.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 6 Feb 2014, Luca Bayer wrote: > John Baldwin <jhb@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.1402060007020.992>