This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [GSoC Project Proposal] ISO C11 threads.h implementation in GNU C Library
- From: Torvald Riegel <triegel at redhat dot com>
- To: Rich Felker <dalias at aerifal dot cx>
- 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: Sun, 13 Apr 2014 17:23:25 +0200
- 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> <20140411235109 dot GU26358 at brightrain dot aerifal dot cx>
On Fri, 2014-04-11 at 19:51 -0400, Rich Felker wrote:
> 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.
Sure, as soon as I get to this, this would be good.
What are you doing in your implementations BTW?
> > > 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.
I suggest to have a look at recent ISO C++ proposals. But given that
you seem to have a pretty strong opinion, I don't see the need to
discuss the details with you further. If anyone else is interested, let
me know.