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

[Florian Weimer]

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;
”

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

Thanks,
Florian