This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [GSoC Project Proposal] ISO C11 threads.h implementation in GNU C Library
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Rich Felker <dalias at aerifal dot cx>
- Cc: Juan Manuel Torres Palma <j dot m dot torrespalma at gmail dot com>, <libc-alpha at sourceware dot org>
- Date: Thu, 27 Feb 2014 21:48:32 +0000
- Subject: Re: [GSoC Project Proposal] ISO C11 threads.h implementation in GNU C Library
- Authentication-results: sourceware.org; auth=none
- References: <CAD82F-pDTRUi1Nh6YiQ-Mx21m6K0NqqvfqZ6ayU9aAACeaVP+w at mail dot gmail dot com> <1393531628 dot 23480 dot 1 dot camel at SamsungRF510> <20140227202310 dot GS184 at brightrain dot aerifal dot cx> <Pine dot LNX dot 4 dot 64 dot 1402272108280 dot 1305 at digraph dot polyomino dot org dot uk> <20140227212605 dot GT184 at brightrain dot aerifal dot cx>
On Thu, 27 Feb 2014, Rich Felker wrote:
> > I don't think separate implementations, with all the complications of
> > associated architecture-dependencies and direct use of many tricky
> > low-level glibc and Linux kernel interfaces, is something that is either
> > reasonably maintainable, or reasonably implementable within the scope of a
> > GSoC project.
>
> There is nothing architecture-dependent involved in implementing these
> primitives. They would all be built on either existing __lll*
> functions or direct use of atomics+futex.
I don't think it's sensible to try building a complicated set of
interfaces on those low-level interfaces for a GSoC project; debugging
problems showing up when using them (often architecture-specific) is too
hard compared to using the pthread_* interfaces that have been debugged
over the course of many years. This project was carefully chosen as
something that is not heavily dependent on glibc internals (beyond
namespace issues); most glibc development ideas would not be suitable for
GSoC.
> Note that POSIX specifies all synchronization primitives as full
> barriers, while C11 has separate release/acquire semantics. This means
> the C11 primitives have the potential to give much better performance
> on architectures where release and acquire barrier semantics are
> distinct.
C11 threads only specify that certain operations synchronize with certain
later operations. In some cases this might mean lesser barriers are
sufficient, but the operations don't have any explicit memory order
parameters.
> > In addition, C11 threads should interact in some reasonable
> > way with POSIX interfaces in programs that use both -
>
> Do you think it's wise to make a public interface guarantee that C11
> mutex pointers can be passed to pthread mutex functions and vice
> versa? I think this would be a big mistake; for example, if semantics
> diverged in any way due to different interpretations, the guarantee
> would have to be retroactively revoked.
Passing pointers like that isn't possible because of the C++ tag issue
already explained.
My point is more about e.g. setuid / setgid in the presence of multiple
threads - there should be a single set of threads, not separate sets of
POSIX and C11 threads, with common infrastructure for doing thread
operations on them, and doing a POSIX operation that affects a C11 thread
should work the same way as when it affects a POSIX thread.
--
Joseph S. Myers
joseph@codesourcery.com