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

[Torvald Riegel <triegel at redhat dot com>]

On Thu, 2014-02-27 at 18:47 -0500, Rich Felker wrote:
> On Thu, Feb 27, 2014 at 09:48:32PM +0000, Joseph S. Myers wrote:
> > 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.
> 
> See below; I don't believe the possibility I've suggested has anything
> to do with glibc internals.
> 
> > > 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.
> 
> I may be mistaken, but I thought C11 mutex unlock had release
> semantics and lock had acquire semantics, rather than both being full
> barriers like they are in POSIX threads.

I agree.  However, in my not so humble opinion, this is a
(specification) defect in POSIX.  We currently don't implement mutexes
as full barriers (depends on the arch), and we shouldn't.

> > > >  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.
> 
> Well GCC (wrongly) treats it as just a warning, and assuming the
> internals are the same, it would even work and be valid if the caller
> casts to (void *).
> 
> > 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.
> 
> Oh, completely. It would be unimaginably stupid to have separate
> implementations of threads. What I'm talking about is having separate
> implementations of synchronization primitives, which have absolutely
> no interdependency with the implementation of threads aside from
> accessing the thread id for recording mutex ownership and similar.

I agree that given how threads are currently implemented, mutex
implementations should be pretty isolated from each other and from the
specifics of the threads implementation.  However, should we ever want
to change how threads look internally, mutexes -- due to being blocking
constructs -- could have an effect on the threads implementations.