More problems with the thread specs

[jacob navia]

This is again a repetition of my warnings of 2010 and 2011. The
difference now is that the standard is already published!
-------------------------------------------------------------

1) Strange use of identifiers.

The standard says (7.25.1.4):
cnd_t
which is a complete object type that holds an identifier for a condition
variable;
thrd_t
which is a complete object type that holds an identifier for a thread;
tss_t
which is a complete object type that holds an identifier for a
thread-specific storage pointer;

The word "identifier" is used elsewhere in the standard with a well
defined meaning.

6.4.2.1:
An identifier is a sequence of nondigit characters (including the
underscore _, the lowercase and uppercase Latin letters, and other
characters) and digits, which designates one or more entities

Now, in this thread chapter the SAME word is used for something
completely different than a sequence of letters without any explanation
at all of what they are talking about!

2) Mysterious symbols nowhere explained
<quote>
7.25.7.1 The xtime_get function

Synopsis
#include <threads.h>
int xtime_get(xtime *xt, int base);

Description
The xtime_get function sets the xtime object pointed to by xt to hold
the current time based on the time base base.

Returns
If the xtime_get function is successful it returns the nonzero value
base, which must be TIME_UTC; otherwise, it returns zero.
<end quote>

2-A: "Time base".
What is that? Is that an epoch (as defined in 7.26.1:
Time since Jan 1st 1900) ?
Or is it a local-time base (UTC) ?

Probably it is the second but nobody knows.

2-B: What is "TIME_UTC" ??? Yes, it is an integer apparently. But what
should it contain? Where is it defined? In which header file? This
symbol appears NOWHERE ELSE IN THE WHOLE STANDARD.

I must remark also that this function returns actually a boolean value:
zero if it fails, or the mysterious "TIME_UTC" integer if it succeeds,
that is the same value of its second argument... Since the resolution of
the "xtime" is system dependent it would have been nice to be able to
query the timer resolution, for instance by doing an xtime_get that
returns the clock resolution in nanoseconds if successful...

3) Ambiguous time intervals
The time functions that use an "xtime". When I want to have a timeout of
(say) 5 seconds, should I:
A: do an xtime_get to get the current time
B: Add 5 seconds to the current time
C: Pass that to the timeout functions

OR
A: pass (xtime){5,0} to the timeout functions?

I.e. do the timeout functions use an xtime that should contain just the
timeout or the current time + the timeout?

This is NOT SPECIFIED!!!

[Jens Gustedt]

Jacob,
I have the impression that you are using an preliminary version of C11.
My copy (n1570) doesn't contain the string xtime, and this whole timing
issue seems to be reworked

Jens

[Jens Gustedt]

Am 04/18/2012 04:13 PM, schrieb jacob navia:
>
> This is again a repetition of my warnings of 2010 and 2011. The
> difference now is that the standard is already published!
> -------------------------------------------------------------
>
> 1) Strange use of identifiers.
>
> The standard says (7.25.1.4):
> cnd_t
> which is a complete object type that holds an identifier for a condition
> variable;
> thrd_t
> which is a complete object type that holds an identifier for a thread;
> tss_t
> which is a complete object type that holds an identifier for a
> thread-specific storage pointer;
>
> The word "identifier" is used elsewhere in the standard with a well
> defined meaning.

But that one isn't really problematic, isn't it? I think a replacement
could simply be:

The types are
cnd_t
which is a complete object type that identifies a condition variable;
thrd_t
which is a complete object type that identifies a thread;
tss_t
which is a complete object type that identifies a thread-specific storage
pointer;
mtx_t
which is a complete object type that identifies a mutex;

Jens

[jacob navia]

Le 18/04/12 16:39, Jens Gustedt a écrit :

>
> But that one isn't really problematic, isn't it? I think a replacement
> could simply be:
>
> The types are
> cnd_t
> which is a complete object type that identifies a condition variable;
> thrd_t
> which is a complete object type that identifies a thread;
> tss_t
> which is a complete object type that identifies a thread-specific storage
> pointer;
> mtx_t
> which is a complete object type that identifies a mutex;
>
> Jens

Yes, that would be much better than this "identifier"word.

[jacob navia]

The second and third issues in my above post (xtime issues) are
corrected in a newer version of the standard.

I apologize for this confusion.

jacob

[lawrenc...@siemens.com]

jacob navia <ja...@spamsink.net> wrote:
> The second and third issues in my above post (xtime issues) are
> corrected in a newer version of the standard.

The actual Standard, as opposed to earlier drafts.

If you had sent your complaints to the committee instead of posting them
here in vain hopes that the committee would notice them, they might all
have been corrected.
--
Larry Jones

It's either spectacular, unbelievable success, or crushing, hopeless
defeat! There is no middle ground! -- Calvin