This is the mail archive of the 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 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.


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