This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 1/8] nptl: Add C11 threads thrd_* functions
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