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

["Joseph S. Myers" <joseph at codesourcery dot com>]

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