This is the mail archive of the
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: Torvald Riegel <triegel at redhat dot com>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, Juan Manuel Torres Palma <j dot m dot torrespalma at gmail dot com>, libc-alpha at sourceware dot org
- Date: Fri, 11 Apr 2014 19:51:09 -0400
- 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> <20140227212605 dot GT184 at brightrain dot aerifal dot cx> <Pine dot LNX dot 4 dot 64 dot 1402272132500 dot 1305 at digraph dot polyomino dot org dot uk> <20140227234707 dot GU184 at brightrain dot aerifal dot cx> <1397253426 dot 10643 dot 18436 dot camel at triegel dot csb>
On Fri, Apr 11, 2014 at 11:57:06PM +0200, Torvald Riegel wrote:
> > 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.
Then you should file a defect report with the Austin Group rather than
silently implementing the interface in a nonconforming manner.
> > 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.
I think that's a vacuous "should we ever". The ridiculous thread
implementation strategies that would require this were already tried
and discredited. This is 2014 not 1998.