Re: glibc -- ISO C11 threads Proposal

[Rich Felker <dalias at aerifal dot cx>]

On Tue, Mar 25, 2014 at 09:01:39PM +0100, Torvald Riegel wrote:
> On Tue, 2014-03-25 at 14:16 -0400, Carlos O'Donell wrote:
> > On 03/25/2014 02:11 PM, Torvald Riegel wrote:
> > > On Sun, 2014-03-16 at 16:50 -0400, Kevin Cox wrote:
> > >> with the following additions (which may be renamed) which will be
> > >> defined if _GNU_SOURCE is defined (this may be discussed and changed).
> > >>
> > >> /* Get the pthread_t corresponding to the passed in thread */
> > >> pthread_t
> > >> thrd_pthread(thrd_t thrd);
> > >>
> > >> /* Get the pthread_mutex_t corresponding to the passed in mutex */
> > >> pthread_mutex_t *
> > >> mtx_pthread(mtx_t *mtx);
> > >>
> > >> /* Get the pthread_cond_t corresponding to the passed in condition
> > >>    variable */
> > >> pthread_cond_t *
> > >> cnd_pthread(cnd_t &thrd);
> > >>
> > > 
> > > I don't think adding these is a good idea.  This would effectively bind
> > > the C11 implementation to use these POSIX synchronization mechanism
> > > forever (or vice-versa).  Getting one of those standards to evolve is
> > > already hard enough.  Furthermore, the fact that you can implement C11
> > > feature with POSIX today doesn't mean that C11's semantics are equal to
> > > POSIX's.
> > 
> > I agree. There should be no binding between the two implementations.
> > No API should allow casting from one to the other.
> > 
> > However, once we implement C11 threads on top of pthreads we are 
> > stuck with the size and alignment of the underlying type. Therefore
> > we may wish to tweak the overlay of the pthreads type onto the C11
> > type e.g. tweak the size up to have some free space for expansion.
> 
> We could also try to make some of the C11 types smaller (or at least not
> make them bigger) to reduce space overhead.  (For example, for
> fine-granular locking.)

I'm generally against making them bigger; the C11 synchronization
objects are MUCH weaker than the POSIX ones in terms of their
specifications/interface contracts, and there's no use for the space
we already have. Making them larger just makes it more expensive to
have synchronization objects as part of other objects, which forces
developers to choose between bloat and coarse-grained locking.

So IMO the question to ask is whether to keep the sizes the same, or
make them smaller. Making them smaller would require new mtx/cond
implementations for C11 but might have some other benefits too,
including performance.

Rich