Re: [PATCH 1/8] nptl: Add C11 threads thrd_* functions

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 15/11/2017 11:35, Florian Weimer wrote:
> On 11/15/2017 02:21 PM, Adhemerval Zanella wrote:
>>
>>
>> On 15/11/2017 10:49, Florian Weimer wrote:
>>> On 11/15/2017 01:43 PM, Adhemerval Zanella wrote:
>>>>
>>>>
>>>> On 15/11/2017 10:03, Florian Weimer wrote:
>>>>> On 11/15/2017 12:22 PM, Adhemerval Zanella wrote:
>>>>>>
>>>>>>
>>>>>> On 15/11/2017 06:09, Florian Weimer wrote:
>>>>>>> On 09/22/2017 10:26 PM, Adhemerval Zanella wrote:
>>>>>>>> This patch adds the thrd_* definitions from C11 threads (ISO/IEC
>>>>>>>> 9899:2011),
>>>>>>>> more specifically thrd_create, thrd_curent, rhd_detach, thrd_equal,
>>>>>>>> thrd_exit, thrd_join, thrd_sleep, thrd_yield, and required types.
>>>>>>>>
>>>>>>>> Mostly of the definitions are composed based on POSIX conterparts,
>>>>>>>> such as
>>>>>>>> thrd_t (using pthread_t).
>>>>>>>
>>>>>>> I have skimmed the C11 discussion of these types, and C11 says that
>>>>>>> mtx_t et al. are “identifiers”.  To me, this suggests they are
>>>>>>> handles, just like pthread_t in the POSIX threads implementation.
>>>>>
>>>>>> My understanding is "identifiers" follow the definition from C11 6.2.1
>>>>>> which does not exclude a tag/struct to represent it.
>>>>>
>>>>> I don't think “identifier” is used in this sense here.
>>>>>
>>>>> The standard says (7.2.6.1/4):
>>>>>
>>>>> “
>>>>> The types are
>>>>> \begin{quote}
>>>>>     \verb|cnd_t|
>>>>> \end{quote}
>>>>> which is a complete object type that holds an identifier for a
>>>>> condition variable;
>>>>> ”
>>>>>
>>>>> The “holds an identifier” suggests to me that this use of the term
>>>>> “identifier” does not refer to the C language construct.  The
>>>>> definitions in ISO/IEC 2382:2015(en) do not seem to be applicable,
>>>>> either.
>>>
>>>> I find it quite inconsistent and improbable that the threads definition
>>>> in C11
>>>> standard is using a defined vocabulary in a different meaning than the rest
>>>> of document.
>>>
>>> But how can a complete object *type* hold a C identifier?  The language does not support that.  We don't have call-by-name or anything like that.
>>
>> Why do we need call-by-name to provide a complete identifier for C11 mtx_t
>> type? My understanding is we have the init functions to initialize the
>> objects and C11 threads avoid static initializers.
> 
> I read “holds” as “stores” in this context, as in:
> 
> “
> \begin{quote}
>     \verb|struct timespec|
> \end{quote}
> which holds an interval specified in seconds and nanoseconds
> ”
> 
> I think using this wording in the context of identifiers is extremely sloppy because an object cannot store an identifier.
> 
> I would have expected language like this if indirection is not required:
> 
> “
> The types are
> \begin{quote}
>     \verb|cnd_t|
> \end{quote}
> which denotes a complete object type which holds a condition variable;
> ”
> 

I agree with you the wording could be more carefully picked in this case,
but the DR for C11 threads also points to a description you put.

>>> So this usage doesn't make sense to me, so I assume that something else is meant here.
>>>
>>> I'm trying to get access to the WG papers on which the text is based. Maybe those illuminate what is meant here.
>>
>>
>> Similar objections were already raised in DR#493 [1], more specifically for
>>
>> "1. What is the behavior of mtx_init() when called with a pointer to an object
>> initialized to all zeros (such as a mutex object with static storage duration)?
>> Are such calls valid, or if not, must the function fail by returning thrd_error,
>> or is its behavior unspecified, or perhaps undefined? (If it is the same as
>> calling it on an uninitialized object then how does one statically initialize a
>> mutex?)"
>>
>> The committee discussion for this specific topic is aiming for:
>>
>> "Problems with mtx_t
>>
>> The semantics of copying a mtx_t are not specified, much like FILE §7.21.3p6."
>>
>> [1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/summary.htm#dr_493
> 
> Oh, this and the rest of the committee response assumes that the synchronization objects are not just identifiers.  I really wish this was specified more explicitly.
> 
> So my concerns are apparently not shared by the committee.

We had some discussion back in v3 about the opened DR for C11 threads [1].
I has the assumption we had no block back then regarding base glibc
implementation on underlying POSIX one.


[1] https://sourceware.org/ml/libc-alpha/2017-03/msg00461.html