C is fixed or not ?

[lawrence.jones]

The original proposal for the C library presented was a copy and paste
of the documentation of Plauger's multi-threading library.

Dinkumware's multi-threading library. Plauger may own the company, but
he doesn't do all the work. (As far as I know, his involvement with the
threads library was minimal.)

 

[Keith Thompson]

That's a perfectly reasonable desire. However, the C committee decided
a LONG time ago that the signal to noise ratio here is far too low for
it to be a useful source of input. I don't frequent comp.std.c++ so I
don't know if it's any better or not, but the C++ committee has a lot
more resources than the C committee does.

Note that "here" is comp.lang.c, not comp.std.c. I find that
comp.std.c has a significantly better S/N ratio that comp.lang.c.
I understand that it may still be too noisy for the C committee to
deal with, but filtering out the noise isn't *that* difficult.

BTW, comp.std.c++ is moderated. I wonder whether a
comp.std.c.moderated newsgroup would be useful, though I wouldn't
want to create it without a prior commitment by the committee to
make use of it. (I haven't decide whether it would be a good idea
even then.)

 

[ImpalerCore]

That is exactly the point of the C1X threads API.  It was specifically
designed (by Dinkumware, who proposed it for inclusion in the Standard)
to be easily implemented as a very thin layer on top of either pthreads
or Windows threads, allowing multithreaded programs to be easily
portable to either system.

If it's so easy to implement, then why not first release a library
version to the C community at large to determine whether it has enough
pull to create a de-facto standard, and then consider standardization
at the language level *if* it's garnered enough interest.

 It does not provide access to all of the
features of either system, but it does provide access to the commonly
used ones in a portable manner.  My understanding is that it is in
active use by Dinkumware itself as well as its customers.

And what percentage of this user group constitutes the C community at
large? It's very likely a useful tool, but without a kind of "Boost
for C" to evaluate these constructs, the vendor uptake of any new
feature is likely to be as sporadic as anything in C99. Where is the
evidence that the C community wants this?

Granted I have the industry connections of a ostrich with its head
stuck in the sand, but a download-able working library might motivate
me to get my head out and take a look, try to use it, and if I like it
spread the word. I may not be able to contribute to the technical
details, but having more widespread positive customer evaluation is a
very important source of information, for doing bold things like
adding to the C standard. And fortunately (or unfortunately depending
on the perspective) the best method to get more widespread evaluation
is to release the software for free.

Best regards,
John D.

 

[jacob navia]

Le 06/07/11 19:27, ImpalerCore a écrit :

If it's so easy to implement, then why not first release a library
version to the C community at large to determine whether it has enough
pull to create a de-facto standard, and then consider standardization
at the language level *if* it's garnered enough interest.


And what percentage of this user group constitutes the C community at
large? It's very likely a useful tool, but without a kind of "Boost
for C" to evaluate these constructs, the vendor uptake of any new
feature is likely to be as sporadic as anything in C99. Where is the
evidence that the C community wants this?

Granted I have the industry connections of a ostrich with its head
stuck in the sand, but a download-able working library might motivate
me to get my head out and take a look, try to use it, and if I like it
spread the word. I may not be able to contribute to the technical
details, but having more widespread positive customer evaluation is a
very important source of information, for doing bold things like
adding to the C standard. And fortunately (or unfortunately depending
on the perspective) the best method to get more widespread evaluation
is to release the software for free.

Best regards,
John D.

I followed that path for my containers library. I published it also in
comp.std.c

Nothing from the committee members, not a single commentary.

But the library of Plauger it is accepted without any problems
even if the specs is full of errors and inconsistencies.

I sent a post into comp.std.c with a detailed critique of that
specifications, explaining each pointed error.

That was 2 years ago. The errors are still there. The only change
is that they renamed "o-type" into an "object type". But the
problem is that they use terms that they dont define since they
just copy/pasted the doc of Plauger.

They introduce a lot of types wihout explaining them. As specifications
go, I have seen better really.

 

[Rui Maciel]

Dinkumware's multi-threading library. Plauger may own the company, but
he doesn't do all the work. (As far as I know, his involvement with the
threads library was minimal.)

Nonetheless, the idea of adopting some proprietary library while
intentionally ignoring a widely established international standard that
cover threads in C, exists for over a decade and was designed specifically
with portability in mind is incomprehensible. It leaves me wondering what
they had in mind when they screwed this up.


Rui Maciel

 

[jacob navia]

Le 06/07/11 20:35, Rui Maciel a écrit :

Nonetheless, the idea of adopting some proprietary library while
intentionally ignoring a widely established international standard that
cover threads in C, exists for over a decade and was designed specifically
with portability in mind is incomprehensible. It leaves me wondering what
they had in mind when they screwed this up.


Rui Maciel

The problem is that (as with many docs of libraries) they do not explain
the CONCEPTS at all.

For instance, the library describes an "xtime" structure that holds
the time in nanoseconds. OK, very useful but absolutely NO functions
are given to convert to/from other time formats already in use in the
current standard like time_t into this new tye that becomes one of the
basic types of the language!

The specs are completely vague:

<quote>
xtime
.... is a structure type that holds a time specified in seconds and
nanoseconds.
<end quote>

Seconds since when? What is the start of that clock? The last
reboot? Jan 1, 1970? or another time?

Nothing, not a word about that.

Then, this type is used in functions like:

<quote>
The cnd_timedwait function atomically unlocks the mutex pointed to by
mtx and endeavors to block until the condition variable pointed to by
cond is signaled by a call to cnd_signal or to cnd_broadcast, or until
after the time specified by the xtime object pointed to by xt.
<end quote>

"After the time" supposes that
a) the time is specified as zero from the moment that function is called
b) the time is specified as the time of the wall clock, i.e. as the
time of the day.

Since that structure is defined as

struct xtime { time_t sec; long nsec;}

you can reasonably suppose that the time_t part is the same as the OTHER
time_t's floating around in other parts of the standard.

Or you can just assume that since the thread timeout is significant
only beginning at the moment the call is made it means that a
value of 1 in the sec member means & timeout of one second and not
midnight and 1 second...

All this is nowhere SPECIFIED.

I sent a detailed critique of this mibrary 2 years ago in comp.std.c

The same errors are STILL THERE!!!

 

[jacob navia]

Le 06/07/11 20:35, Rui Maciel a écrit :

Nonetheless, the idea of adopting some proprietary library while
intentionally ignoring a widely established international standard that
cover threads in C, exists for over a decade and was designed specifically
with portability in mind is incomprehensible. It leaves me wondering what
they had in mind when they screwed this up.


Rui Maciel

As I said in my other message, the TERMS
aren't explained.

What is "a thread"?

Nobody knows, it is just left "as an exercise to the reader".

No way to start a thread in a suspended state. Why?

Because the thread creation function doesn't allow for any PARAMETERS
to be passed to the underlying OS!

pthreads specifies an attributes argument that can be used to further
specify the behavior of the new thread.

The microsoft API specifies security attributes and a set of flags.

So, the C API specifies NOTHING, impossible to specify any
attributes!!!!

How can anybody THINK that this will be accepted by the users?
It is completely NUTS.

Yes, you can always use the default attributes
but since they are then compiler dependent, there is no way your code
will behave the same in different implementations of the API even in the
same machine!!! If compiler "A" decides to default to some
attributes XXX, and another to attributes YYY, your code will
behave differently in the SAME MACHINE.

GREAT!

Look, those specs are so ridiculous that I would laugh if it weren't so
sad.

 

[Ian Collins]

Where does ISO/IEC 9899:1999 define lock-free types?

It doesn't. There is nothing threading related in C99.

 

[Ian Collins]

Le 06/07/11 10:10, Ian Collins a écrit :

The original proposal for the C library presented was a copy and paste
of the documentation of Plauger's multi-threading library.

Ah OK. But you said "pushed this into C++ apparently". I was referring
to the C++ papers.

 

[Ian Collins]

Actually he works for http://dinkumware.com/ who produce libraries for
many compiler companies of whom Microsoft is but one.


I would agree that C does not need it.


Which bit that he works for Microsoft? (which he clearly doesn't at
least not more than any other compiler company)

Or the threading stuff?

The claim that "Plauger pushed this into C++ apparently". The C++
threading model derived from boost and atomics (with is the common
ground between C and C++) from a number of proposals not written by PJP.

 

[Ian Collins]

That's a perfectly reasonable desire. However, the C committee decided
a LONG time ago that the signal to noise ratio here is far too low for
it to be a useful source of input. I don't frequent comp.std.c++ so I
don't know if it's any better or not, but the C++ committee has a lot
more resources than the C committee does.

I agree with Keith. comp.std.c is a very low noise group. I don't see
anything there that wouldn't appear on a moderated group. It could be
used as a valuable source of ideas and feedback.

From what I've seen, compared to C the C++ standardisation process is
more open and inclusive.

 

[Rui Maciel]

That is exactly the point of the C1X threads API. It was specifically
designed (by Dinkumware, who proposed it for inclusion in the Standard)
to be easily implemented as a very thin layer on top of either pthreads
or Windows threads, allowing multithreaded programs to be easily
portable to either system.

This argument is absurd, as pthreads was from the start designed with
portability in mind and even Microsoft already provides a pthreads
implementation. The only reason why Microsoft opted to avoid pthreads and
instead go with their home-brew version of a threading API is their
pathological reaction to open standards and their need to artificially
hinder anything remotely related to portability.

Now, by intentionally neglecting a widely adopted international standard for
a threading API for the C which which already exists for over a decade,
those who push this absurd initiative are essentially forcing the C
standardization process to incorporate a dumb approach to a problem which is
not technical and instead caused by nothing more than a single company's
refusal to respect, let alone follow standards.


Rui Maciel

 

[Keith Thompson]

That is exactly the point of the C1X threads API. It was specifically
designed (by Dinkumware, who proposed it for inclusion in the Standard)
to be easily implemented as a very thin layer on top of either pthreads
or Windows threads, allowing multithreaded programs to be easily
portable to either system. It does not provide access to all of the
features of either system, but it does provide access to the commonly
used ones in a portable manner. My understanding is that it is in
active use by Dinkumware itself as well as its customers.

I'm not very familiar with this area, but why would just
incorporating POSIX threads (or perhaps a subset of POSIX threads)
into the C standard not have been a good solution?

(This is basically the same question Rui Maciel asked, but without
the, um, colorful observations.)

 

[Shao Miller]

(e-mail address removed) wrote:


This argument is absurd, as pthreads was from the start designed with
portability in mind and even Microsoft already provides a pthreads
implementation.

Or bought one. I believe that Interix was acquired.

The only reason why Microsoft opted to avoid pthreads and
instead go with their home-brew version of a threading API is their
pathological reaction to open standards and their need to artificially
hinder anything remotely related to portability.

That doesn't seem quite right. NT has the concept of "subsystems."
POSIX is an example of a subsystem. Win32 is another example of a
subsystem. It seems natural that pthreads belongs with the POSIX
subsystem. Win32 components are mostly compatible with 32-bit,
pre-NT Windows, which didn't have subsystems; Windows 95 is an
example (16 years ago).

Now, by intentionally neglecting a widely adopted international standard for
a threading API for the C which which already exists for over a decade,
those who push this absurd initiative are essentially forcing the C
standardization process to incorporate a dumb approach to a problem which is
not technical and instead caused by nothing more than a single company's
refusal to respect, let alone follow standards.

Which company do you mean?

 

[James Kuyper]

You didn't understand what I said. ...

Yes I did, I just don't agree with it.

... The reason why it is irrelevant to
compare similarities between both APIs is that,

It's the differences, not the similarities, that I wanted to compare.

... as it was acceptable to
create a brand new standard that covers the exact same subject that a widely
establised standard already covers for over a decade, then it would also be
acceptable to update any part of the pre-existing standard which might need
updating. This would simplify the C 201x standardization process a great
deal. If the new C 201x standard simply added somewhere in the text the
following snippet:

"In ISO/IEC 9899:201x, the support for threads is intended to be in
conjunction with:
- IEEE Std 1003.1c-1995 - POSIX threads API" ....

You are talking about POSIX threads as if they were some foreign API which
was impossible to implement in any OS.

Those concepts were not in my head when I wrote those words, and I can't
find them in the words I wrote. I think they're your own invention. You
might get a little closer to what I actually meant if you replace
"impossible to implement in any OS" with "difficult to implement
efficiently for some OSs", but I didn't say anything sufficiently
specific to justify even that rewording.

API but also is technically incapable of supporting it. As I've already
pointed out, even Microsoft provides pthreads for the Windows platform.

As I've learned from other messages on this thread, Dinkumware created a
threading library that heavily influenced the proposal for threading
support in the next C standard. They could have simply relied upon
Microsoft's implementation of POSIX pthreads, but they chose not to. I
don't know what their reasons were for that decision; do you? If so, can
you express those reasons in a way that Dinkumware could agree was an
accurate description? Your attempt in you message containing the header
"Date: 07 Jul 2011 00:21:17 +0100" doesn't qualify.

I doubt that they did it out of sheer random spite; if they had a valid
reason for doing so, that reason might apply to the C standard as well;
the fact that the C committee is considering this proposal suggests that
a fair number of committee members think the reasons are valid, which is
why I'd be very interested in getting an objective description of those
reasons. Somehow, I doubt that you're the best source for that description.

Understand - I'm not arguing in favor of this change. I think that
there's currently too much overlap between the POSIX and C standards;
increasing that overlap seems a move in the wrong direction - but I'm
open to the idea that it might be well motivated, and I'm waiting to
hear what those motivations might be.

... So,
knowing this, why do you refer to pthreads as something other than a
standard for implementing threads in a portable and flexible way?

I don't; that's just your imagination filling in details incorrectly.

 

[Shao Miller]

subsystem. Win32 components are mostly compatible with 32-bit,
pre-NT Windows, which didn't have subsystems; Windows 95 is an
example (16 years ago).

"Pre-NT" is a mistaken term. What I ought to have written was
"non-NT".

But anyway, it's all history... That Microsoft developed NT with
subsystems (and POSIX support) in the first place doesn't suggest a
blatant disregard for standards.

 

[lawrence.jones]

I followed that path for my containers library. I published it also in
comp.std.c

And everyone proclaimed it the most wonderful thing they've ever seen,
wondered how they'd gotten along without it all these years, and
instantly adopted it, right?

Nothing from the committee members, not a single commentary.

For the umpteeth time, the committee does not read comp.std.c or any
other newsgroup.

But the library of Plauger it is accepted without any problems
even if the specs is full of errors and inconsistencies.

Proposals do not have to be perfect to get adopted into the working
draft, they just have to be "good enough" that there is some confidence
that the remaining problems can be worked out before the standard is
adopted. Including such proposals into the working draft encourages
people to comment on them.

I sent a post into comp.std.c with a detailed critique of that
specifications, explaining each pointed error.

Too bad you didn't submit it to the committee where it might have done
some good.

That was 2 years ago. The errors are still there. The only change
is that they renamed "o-type" into an "object type".

That is not correct, there have been a number of changes and
corrections. Please see the most recent working draft, N1570.

 

[lawrence.jones]

This argument is absurd, as pthreads was from the start designed with
portability in mind and even Microsoft already provides a pthreads
implementation.

Yes, and POSIX was from the start designed with portability in mind and
even Microsoft already provides a POSIX implementation. And absolutely
no one uses it. pthreads was designed for Unix-like systems, period.

 

[lawrence.jones]

I'm not very familiar with this area, but why would just
incorporating POSIX threads (or perhaps a subset of POSIX threads)
into the C standard not have been a good solution?

My understanding, from people who know a whole lot more about it than I
do, is that POSIX threads cannot be implemented on top of Windows
because it presupposes a bunch of POSIX features that Windows doesn't
provide, at least in the form that POSIX threads requires.

 

[jacob navia]

Le 07/07/11 06:19, (e-mail address removed) a écrit :

And everyone proclaimed it the most wonderful thing they've ever seen,
wondered how they'd gotten along without it all these years, and
instantly adopted it, right?


For the umpteeth time, the committee does not read comp.std.c or any
other newsgroup.

But YOU participated to that discussion and were aware of my
criticism. The message you sent in that discussion
was sent on June 8 2009 at 11:52pm

You can read it here
https://groups.google.com/group/comp.std.c/browse_thread/thread/e56830127972f358?hl=en

Mr Jones: It is very easy to laugh at me. I have no money to go to your
meetings, and the C group in France has disappeared because the AFNOR
decided so.

It would be more honest to see that I have worked for YEARS (at least
ten) to implement C99, to participate in the C community, to make
proposals to improve the language, and that I still go on working
for the C community.

You haven't even read the containers proposals, you have not even
bothered to consider the whole idea. You just spread your arrogance
around as it was the thing to do.

I am not your enemy, but you, apparently, are convinced that you have
to crush me at each post.