This is the mail archive of the libc-alpha@sourceware.org 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: glibc -- ISO C11 threads Proposal


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.


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