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: Rich Felker <dalias at aerifal dot cx>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- 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 16:26:05 -0500
- 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>
On Thu, Feb 27, 2014 at 09:15:06PM +0000, Joseph S. Myers wrote:
> On Thu, 27 Feb 2014, Rich Felker wrote:
>
> > I'm probably getting ahead of things here, but for what it's worth,
> > one of the big questions that's been open so far is whether C11
> > synchronization objects should just reuse the pthread objects and
> > implementations, or have their own versions. Since C11 semantics are
> > much weaker, there could be potential performance benefits to having
> > separate implementations, and since C11 has fewer features, the
> > objects themselves could possibly be significantly smaller (which has
> > a major impact on the cost of including them in structures that exist
> > in many instances). However I'm not sure whether these benefits
> > outweigh the cost of having separate implementations. If your proposal
> > is accepted, I think this is a major area you should research and
> > present pros/cons on during the early stages.
>
> 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.
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.
> 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.
Anyway I don't think it's at clear as you make it out to be which
approach should be preferred. That's why I'd like to see some research
on the pros and cons.
Rich