Re: [GSoC Project Proposal] ISO C11 threads.h implementation in GNU C Library

[Rich Felker <dalias at aerifal dot cx>]

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