This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc -- ISO C11 threads Proposal
- From: Torvald Riegel <triegel at redhat dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: Rich Felker <dalias at aerifal dot cx>, Kevin Cox <kevincox at kevincox dot ca>, libc-alpha at sourceware dot org
- Date: Fri, 28 Mar 2014 21:18:56 +0100
- Subject: Re: glibc -- ISO C11 threads Proposal
- Authentication-results: sourceware.org; auth=none
- References: <53260E7E dot 8070308 at kevincox dot ca> <1395771092 dot 19076 dot 1236 dot camel at triegel dot csb> <5331C7EA dot 6050407 at redhat dot com> <1395777699 dot 19076 dot 1469 dot camel at triegel dot csb> <20140325212732 dot GC26358 at brightrain dot aerifal dot cx> <53337E8B dot 50508 at kevincox dot ca> <20140327015642 dot GF26358 at brightrain dot aerifal dot cx> <1395937708 dot 19076 dot 2997 dot camel at triegel dot csb> <20140327170447 dot GJ26358 at brightrain dot aerifal dot cx> <53350719 dot 6090401 at redhat dot com>
On Fri, 2014-03-28 at 01:22 -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.
>
> > 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. Starting with C11 objects
> that are the size of pthread ones is as good a starting place as
> any.
What do you think is the likelihood of us actually down-sizing the mutex
types eventually? Do you really think this will happen?
> 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.
But "nice to have" comes with a cost.