Problems with document n1372.pdf
jacob navia
(http://www.open-std.org/jtc1/sc22/wg14/www/docs/PostMarkham.htm)
There is a title
"N1372 2009/03/23 Plauger, Threads for the C Standard Library "
I have tried to understand this document but it is completely
impossible since there is absolutely no explanation of any of the
terms used in the description of this functions.
I assume that there must be another document that explains the terms
used but I did not find any.
Where should I look for? The document mentions
"As discussed in the WG14 meeting held in Delft in April of 2008"
Are any documents concerning that meeting available?
Thanks
Lew Pitcher
wrote:
> In the "Post markham" document
> (http://www.open-std.org/jtc1/sc22/wg14/www/docs/PostMarkham.htm)
> There is a title
> "N1372 2009/03/23 Plauger, Threads for the C Standard Library "
>
> I have tried to understand this document but it is completely
> impossible since there is absolutely no explanation of any of the
> terms used in the description of this functions.
Jacob,
I don't know of any Standards committee document that describes the
terminology of threading. However, the terms in the N1372 paper seem
consistant with standard computer science terminology.
Can you elucidate on which N1372 terms you need some explanation of?
--
Lew Pitcher
Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------
Golden California Girls
It is a stupid idiotic attempt by the C committee to make POSIX threads and
Windows threads conform to their idea of threads. All it does is double the
linker overhead and make the committee feel as if it is doing something
important while delaying them from doing real hard work like removing all the
broken bloat they have already added.
jacob navia
> On June 8, 2009 13:37, in comp.std.c, jacob navia (ja...@jacob.remcomp.fr)
> wrote:
>
>> In the "Post markham" document
>> (http://www.open-std.org/jtc1/sc22/wg14/www/docs/PostMarkham.htm)
>> There is a title
>> "N1372 2009/03/23 Plauger, Threads for the C Standard Library "
>>
>> I have tried to understand this document but it is completely
>> impossible since there is absolutely no explanation of any of the
>> terms used in the description of this functions.
>
> Jacob,
>
> I don't know of any Standards committee document that describes the
> terminology of threading. However, the terms in the N1372 paper seem
> consistant with standard computer science terminology.
>
> Can you elucidate on which N1372 terms you need some explanation of?
>
>
Obviously I know what windows threads are. I know too that several OTHER
thread models exist. It is obvious that before using any term like
"threads" the standard has to define what is understood under that
term... Windows threads? Unix pthreads model?
It is impossible without a formal explanation to be able to infere
what that document wants.
For instance:
Example 1:
----------
int cnd_broadcast(cnd_t *cond);
The cnd_broadcast function unblocks all of the threads that are blocked
on the condition variable pointed to by cond at the time of the call. If
no threads are blocked on the condition variable pointed to by cond at
the time of the call, the function does nothing.
Great.
And what is a "cnd_t" ???
Under "Types" the document says:
cnd_t
typedef o-type cnd_t;
The type is an object type o-type that holds an identifier for a
condition variable
Great... but "o-type" is NOWHERE explained. This is obviously
"information hiding" :-)
This is an "o-type that holds an identifier"... What THAT could
mean?
Normally identifiers are bound to objects but an object that
holds an identifier?
You will see that all types are o-types.
Since o-types are nowhere explained in the document I suppose
that it is a place holder for something...
Another example:
Example 2:
----------
int tss_create(tss_t *key, tss_dtor_t dtor);
The tss_create function creates a thread-specific storage pointer with
destructor dtor, which may be null.
Yes, I know what a destructor is in C++.
But in C?
I am surprised that
this terminology is used without any further explanation...
In the "Types" section we read
tss_dtor_t
typedef void (*tss_dtor_t)(void*);
The type is the function type for a destructor for a thread-specific
storage pointer.
Great.
But... no hints as to WHEN that destructor should be called?
Yes, there is a function "tss_delete" but it doesn't mention
the destructor. Is it optional then?
The document goes on like that, without any sense in the terms used
or what the many functions should do in most cases...
Example 3:
----------
int xtime_get(xtime *xt, int base);
The xtime_get function sets the xtime object pointed to by xt to hold
the current time based on the time base base.
What is a "time base"???
Nowhere is this concept mentioned again. In the whole document
this is the only place where this concept appears.
An xtime, by the way, is explained in the types section with
struct { time_t sec; long nsec; };
The type is a structure that holds a time sec in seconds plus a time
nsec in nanoseconds.
Great. We will AT LAST have a nanosecond time in the standard, very good!
But since there are no standard functions to
a) Convert a time_t into xtime
b) Print an xtime
c) input an xtime (other than with that mysterious "base")
the utility of it seems limited to me.
I can repeat the examples with most of those functions listed in
the document. The whole things seems (to me) to be a part of
a greater document that is somehow missing.
-------------------------------------------------------------------
Obviously this is meant as a constructive critique... I find it
EXCELLENT that the standards committee works in this direction.
Lew Pitcher
wrote:
> Lew Pitcher wrote:
>> On June 8, 2009 13:37, in comp.std.c, jacob navia
>> (ja...@jacob.remcomp.fr) wrote:
>>
>>> In the "Post markham" document
>>> (http://www.open-std.org/jtc1/sc22/wg14/www/docs/PostMarkham.htm)
>>> There is a title
>>> "N1372 2009/03/23 Plauger, Threads for the C Standard Library "
>>>
>>> I have tried to understand this document but it is completely
>>> impossible since there is absolutely no explanation of any of the
>>> terms used in the description of this functions.
>>
>> Jacob,
>>
>> I don't know of any Standards committee document that describes the
>> terminology of threading. However, the terms in the N1372 paper seem
>> consistant with standard computer science terminology.
>>
>> Can you elucidate on which N1372 terms you need some explanation of?
>>
>>
>
> Obviously I know what windows threads are. I know too that several OTHER
> thread models exist. It is obvious that before using any term like
> "threads" the standard has to define what is understood under that
> term... Windows threads? Unix pthreads model?
My guess is "C threads"; a threading model for the C language that C
implementations can map onto the native threading model for their platform.
In that case, the "C threads" model would present a simplified model,
without the platform-specific "tuning knobs" that Windows threads and POSIX
threads require.
> It is impossible without a formal explanation to be able to infere
> what that document wants.
Hmmmmmmmmm..... I don't know about that....
> For instance:
>
> Example 1:
> ----------
>
> int cnd_broadcast(cnd_t *cond);
>
> The cnd_broadcast function unblocks all of the threads that are blocked
> on the condition variable pointed to by cond at the time of the call. If
> no threads are blocked on the condition variable pointed to by cond at
> the time of the call, the function does nothing.
>
> Great.
>
> And what is a "cnd_t" ???
>
> Under "Types" the document says:
>
> cnd_t
>
> typedef o-type cnd_t;
>
> The type is an object type o-type that holds an identifier for a
> condition variable
>
> Great... but "o-type" is NOWHERE explained. This is obviously
> "information hiding" :-)
I would think that an "o-type" is something that the implementor has to
determine, based on how s/he maps this C threading model onto the native
model for the target platform. Much like the base type for the existing
time_t (which the standard only says is a "arithmetic type capable of
representing times", and /doesn't/ say is specifically an "int" or
a "float").
> This is an "o-type that holds an identifier"... What THAT could
> mean?
Perhaps that an arbitrary o-type is likely to be a complex type, such as a
struct?
> Normally identifiers are bound to objects but an object that
> holds an identifier?
>
> You will see that all types are o-types.
>
> Since o-types are nowhere explained in the document I suppose
> that it is a place holder for something...
>
> Another example:
>
> Example 2:
> ----------
>
> int tss_create(tss_t *key, tss_dtor_t dtor);
>
> The tss_create function creates a thread-specific storage pointer with
> destructor dtor, which may be null.
>
> Yes, I know what a destructor is in C++.
>
> But in C?
Think what free() does. Isn't /that/ a "destructor"?
> I am surprised that
> this terminology is used without any further explanation...
>
> In the "Types" section we read
>
> tss_dtor_t
>
> typedef void (*tss_dtor_t)(void*);
>
> The type is the function type for a destructor for a thread-specific
> storage pointer.
>
> Great.
>
> But... no hints as to WHEN that destructor should be called?
> Yes, there is a function "tss_delete" but it doesn't mention
> the destructor. Is it optional then?
Yes, because tss_create() permits a NULL dtor.
When should the destructor be called? Why, when tss_delete() is called.
Think of the tss_create() as, in part, providing a thread-specific atexit()
list; that's the destructor. When tss_delete() is called, the stored
destructor (from the tss_create() call) is invoked to clean up the memory.
> The document goes on like that, without any sense in the terms used
> or what the many functions should do in most cases...
>
> Example 3:
> ----------
>
> int xtime_get(xtime *xt, int base);
>
> The xtime_get function sets the xtime object pointed to by xt to hold
> the current time based on the time base base.
>
> What is a "time base"???
Good question.
> Nowhere is this concept mentioned again. In the whole document
> this is the only place where this concept appears.
>
> An xtime, by the way, is explained in the types section with
>
> struct { time_t sec; long nsec; };
> The type is a structure that holds a time sec in seconds plus a time
> nsec in nanoseconds.
>
> Great. We will AT LAST have a nanosecond time in the standard, very good!
>
> But since there are no standard functions to
> a) Convert a time_t into xtime
> b) Print an xtime
> c) input an xtime (other than with that mysterious "base")
>
> the utility of it seems limited to me.
>
> I can repeat the examples with most of those functions listed in
> the document. The whole things seems (to me) to be a part of
> a greater document that is somehow missing.
>
> -------------------------------------------------------------------
>
> Obviously this is meant as a constructive critique... I find it
> EXCELLENT that the standards committee works in this direction.
Your points are well-taken (by me, at least). ISTM that the n1372
document /extends/ some other document that describes a "C threading"
model. /That's/ the document that you need.
Keith Thompson
[...]
> Example 1:
> ----------
>
> int cnd_broadcast(cnd_t *cond);
>
> The cnd_broadcast function unblocks all of the threads that are
> blocked on the condition variable pointed to by cond at the time of
> the call. If no threads are blocked on the condition variable pointed
> to by cond at the time of the call, the function does nothing.
>
> Great.
>
> And what is a "cnd_t" ???
>
> Under "Types" the document says:
>
> cnd_t
>
> typedef o-type cnd_t;
>
> The type is an object type o-type that holds an identifier for a
> condition variable
>
> Great... but "o-type" is NOWHERE explained. This is obviously
> "information hiding" :-)
>
> This is an "o-type that holds an identifier"... What THAT could
> mean?
I took "o-type" to mean "object type". Compare the definition of in
C99 7.19.1p2:
FILE
which is an object type capable of recording ...
I agree that this should have been stated more clearly.
[snip]
> Normally identifiers are bound to objects but an object that
> holds an identifier?
I suspect that "identifier" is being used in the sense of "something
that identifies something", not in the usual sense of a C lexical
token. Again, this should have been stated more clearly.
[snip]
> Example 3:
> ----------
>
> int xtime_get(xtime *xt, int base);
>
> The xtime_get function sets the xtime object pointed to by xt to hold
> the current time based on the time base base.
>
> What is a "time base"???
>
> Nowhere is this concept mentioned again. In the whole document
> this is the only place where this concept appears.
>
> An xtime, by the way, is explained in the types section with
>
> struct { time_t sec; long nsec; };
> The type is a structure that holds a time sec in seconds plus a time
> nsec in nanoseconds.
>
> Great. We will AT LAST have a nanosecond time in the standard, very good!
>
> But since there are no standard functions to
> a) Convert a time_t into xtime
time_t t = /*whatever*/;
xtime now = { t, 0 };
> b) Print an xtime
Print the sec member using whatever method you like (there's no direct
way to print a time_t either), then use "%.09ld" to print the nsec
member.
[snip]
> Obviously this is meant as a constructive critique... I find it
> EXCELLENT that the standards committee works in this direction.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
lawrenc...@siemens.com
>
> Where should I look for? The document mentions
> "As discussed in the WG14 meeting held in Delft in April of 2008"
>
> Are any documents concerning that meeting available?
Of course -- all the committee documents are available on the web site:
<http://www.open-std.org/jtc1/sc22/wg14/www/documents>
You're probably looking for N1287 from the Pre-Delft mailing.
--
Larry Jones
In short, open revolt and exile is the only hope for change? -- Calvin
lawrenc...@siemens.com
>
> It is a stupid idiotic attempt by the C committee to make POSIX threads and
> Windows threads conform to their idea of threads.
Only in the same sense that the standard I/O library was a stupid
itiotic attempt by DMR and friends to make Unix I/O conform to their
idea of I/O. The threads library is intended to be a thin portability
layer that provides a common interface to the most useful threads
functionality and that can be easily implemented on any underlying
thread support (of which there are many, not just the two you mention).
--
Larry Jones
Why can't I ever build character in a Miami condo or a casino somewhere?
-- Calvin
James Kuyper
> On June 8, 2009 16:39, in comp.std.c, jacob navia (ja...@jacob.remcomp.fr)
> wrote:
>> Example 2:
>> ----------
>>
>> int tss_create(tss_t *key, tss_dtor_t dtor);
>>
>> The tss_create function creates a thread-specific storage pointer with
>> destructor dtor, which may be null.
>>
>> Yes, I know what a destructor is in C++.
>>
>> But in C?
>
> Think what free() does. Isn't /that/ a "destructor"?
No, that's a deallocator. In C++, when an object's lifetime ends, the
destructor is called to perform whatever user-defined cleanup of the
object is required before the appropriate deallocator is called to
deallocate the memory that the the object is stored in. It's perfectly
feasible, though dangerous, to destroy an object without deallocating
the memory, and to deallocate the memory without destroying the object.
There are even (on very rare occasions) good reasons to do so.
For an example of the kind of cleanup that a destructor does, consider
an object that contains a pointer to dynamically allocated memory which
is owned by that object. The destructor would deallocate that memory
(usually, but not necessarily, after destroying any objects which were
constructed in that memory). Similarly, if the object contained a FILE*
that it owns, it would generally close the file it refers too.
In typical C code, the code that serves the same purpose as a C++
destructor is not necessarily organized into a separate special
function. However, it could be, and if you're using tss_create(), you
would have to do so, because you would need to pass a pointer to that
function as the second argument of tss_create().
Richard Bos
> An xtime, by the way, is explained in the types section with
>
> struct { time_t sec; long nsec; };
> The type is a structure that holds a time sec in seconds plus a time
> nsec in nanoseconds.
>
> Great. We will AT LAST have a nanosecond time in the standard, very good!
>
> But since there are no standard functions to
> a) Convert a time_t into xtime
> b) Print an xtime
> c) input an xtime (other than with that mysterious "base")
>
> the utility of it seems limited to me.
Frankly, I'm more worried that this seems to presuppose that a time_t
_must_ be in seconds. That's never been a requirement in C.
Richard