Re: glibc -- ISO C11 threads Proposal

["Carlos O'Donell" <carlos at redhat dot com>]

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. 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.

Cheers,
Carlos.