This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.

> > >  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.
Dropping in a replacement for these functions should in concept always
be easy, and I believe it's likewise easy to have separate pthread and
C11 primitives.

Rich


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]