This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc -- ISO C11 threads Proposal
- From: Rich Felker <dalias at aerifal dot cx>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: Kevin Cox <kevincox at kevincox dot ca>, Carlos O'Donell <carlos at redhat dot com>, libc-alpha at sourceware dot org
- Date: Thu, 27 Mar 2014 13:04:47 -0400
- 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>
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.)
However, from an implementation standpoint, making them smaller
precludes implementing the C11 synchronization objects using the
pthread ones. That may be an unacceptable limitation.
Rich