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: [PATCH 1/8] nptl: Add C11 threads thrd_* functions



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. 

>
> The POSIX model assumes that the identity of a condition variable is
> determined by its address.  This means that pthread_cond_t cannot hold
> an identifier, it is the thing itself, which means, among other
> things, that you cannot make a copy (e.g. using memcpy) and the copy
> will behave in the same way as the original, accessing the same
> condition variable.
>
> If something is just an identifier for something else, it strongly
> suggests to me that the underlying object is separate, and I can use a
> bit-wise identical identifier to reference the identical underlying
> object.

My understanding is C11 threads standard does not create a tightly
definition
to try accommodate possible implementations where POSIX assumptions are
not required or exercised. However I do not see that a more constrict
implementation (based on POSIX for instance) is incompatible, the link I
provided
earlier is a suggestion to add features test to define which constraints are
defined in the environment.

Also the defined C11 threads API does not suggest me that the idea of the
types are to point to a concrete identifier. For instance, to compare
threads
C11 does provide thrd_equal instead of relying of memcmp for the defined
objects (as for bitwise underlying objects).



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