Re: glibc -- ISO C11 threads Proposal

[Rich Felker <dalias at aerifal dot cx>]

On Fri, Mar 28, 2014 at 01:22:33AM -0400, Carlos O'Donell wrote:
> On 03/27/2014 01:04 PM, Rich Felker wrote:
> > On Thu, Mar 27, 2014 at 05:28:28PM +0100, Torvald Riegel wrote:
> >> On Wed, 2014-03-26 at 21:56 -0400, Rich Felker wrote:
> >>> On Wed, Mar 26, 2014 at 09:27:39PM -0400, Kevin Cox wrote:
> >>>> On 25/03/14 17:27, Rich Felker wrote:
> >>>>> 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:
> >>>>>>
> >>>>>> 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.
> >>>>>
> >>>>
> >>>> I think for this project it is best to leave them as the pthread ones.
> >>>> Since I will be removing the translation functions we will be free to
> >>>> "upgrade" them in the future if desired.
> >>>
> >>> So in that case, the object sizes (for ABI purposes) will match the
> >>> pthread ones. Is that ok with everyone?
> >>
> >> I believe this is something we'll have to discuss (and investigate) some
> >> more at least before the C11 support becomes non-experimental.  I don't
> >> think this needs to be necessarily decided before or during the GSoC
> >> project.
> >>
> >> I also guess that the sizes of the pthreads objects should be rather on
> >> the large than the small size, so they could be sufficient; OTOH, making
> >> the C11 objects smaller if possible also has benefits.
> > 
> > From an application standpoint, smaller is much nicer. Having a small
> > mutex, for example, would encourage using it rather than NIH'ing it
> > with atomics. And even in cases where NIH'ing isn't an issue, a
> > smaller mutex could halve memory consumption for some data structures.
> > (It should be possible to achieve C11 mutex semantics with just two
> > ints.)
> 
> We can't prevent users from wanting synchronization primitives
> that map directly onto their requirements, and it's hard to provide
> in a general purpose library. Our aim shall always be to provide
> primitives that are good enough for most uses and are written by
> experts who understand the details of a correct implementation.

Yes, but admittedly it is rather frustrating that the portable way to
make mutex-protected objects is too memory-hungry for many usage
cases...

> > However, from an implementation standpoint, making them smaller
> > precludes implementing the C11 synchronization objects using the
> > pthread ones. That may be an unacceptable limitation.
> 
> A minimal C11 synchronization object has no room for error, it has
> to be right the first time. If my experience has taught me anything
> is that eventually everything is wrong.

Agreed. I think it would be moderately risky to start off with a very
small size, despite the benefits...

> Starting with C11 objects
> that are the size of pthread ones is as good a starting place as
> any.

...and yes, I feel like this is the best choice.

> I have always lamented that pthread objects didn't have some
> extra space for debugging information, and the recent elision usage
> of some remaining unused bits only goes further to remind me that
> free space is nice to have.

FYI, glibc is currently wasting at least one slot. There's no reason
to have separate futex and owner fields, and doing so actually
precludes making recursive and error-checking mutexes reentrant. Since
my implementation doesn't waste an extra slot on owner, it has enough
slots in the 32-bit structure to store both prev/next pointers for
robust mutexes, making them O(1) instead of O(n). This will turn out
to be even more important for solving the tid reuse issue (where a
mutex that was left locked by a thread that exited could be
misinterpreted by a new thread that happens to get the same tid); as
far as I can tell, the only reasonable solution is implementing
recursive and error-checking mutexes internally as robust mutexes, but
assigning them a permanent dummy owner them rather than giving
EOWNERDEAD when they're found in "owner died" state.

Rich