C is fixed or not ?

[Joshua Maurice]

Please note: I've added comp.unix.programmer (for the POSIX aspects)
and comp.programming.threads (for the threading aspect)

We've been discussing the next revision of the C standard (C1X)http://en.wikipedia.org/wiki/C1X
Specifically, the inclusion of multi-threading support.

Apparently, Dinkumware's library is being considered, and some
are wondering why the committee did not consider adopting the
POSIX API itself, or a subset thereof.

Would enlightened people in either comp.unix.programmer or
comp.programming.threads comment on these aspects?

Why didn't they adopt the POSIX API itself? I suspect a couple of
reasons.

First compatibility with C++0x. Of course, that begs the question of
why didn't the C, C++, and POSIX committees when working together
decide to adopt the POSIX pthreads standard?

Second, the POSIX pthreads standard is underspecified, and incomplete,
and slightly buggy. It's buggy in the informal simple specification of
try_lock. It's incomplete because it's missing all of the non
sequentially consistent atomics, eg: fences and such. And if you're
going to specify fences portably, you need a rigorously defined memory
model, which C++0x and C1x will give you.

In spirit, C1x and C++0x are compatible in spirit with POSIX pthreads.
They will give you the same primitives with different names, more or
less.

Finally, I suppose you could ask why not fix and extend POSIX
pthreads? They may have been political, see: Windows. Perhaps they
thought they had a better chance to drag Windows kicking and screaming
if they made a new standard?

 

[MikeP]

Sure. Most of the synchronization objects in Windows are system wide.

CAN be. If you name them, THEN they can be used amongst processes.
Unnamed synch objects are intra-process. Whether having unnamed synch
objects makes them lighter-weight (higher performance) in usage, I don't
know. Simple enough to profile though.

 

[MikeP]

Windows SFU gets you a pretty good Unix environment, where you can
compile and run your Unix applications. It is largely separate from
the Windows API side of things, and there's little or no ability to
use the Windows APIs in an WSFU application (or vice versa).

So the fact that MS (with some outside help) has implemented WSFU on
top of the NT native API (which is *not* the Win32 API, but the Win32
API is built on top of the native API too),

I hypothesize that SOME of the Win32 is built on top of native, but not
ALL or even MOST of it. The low-level native has to exist for capability
or performance reasons, but once enough code is laid down to work at a
higher level of abstraction, and when one can, one does (they do),
surely. (By "built on top of" I mean, "implemented in terms of",
actually).

 

[MikeP]

Well, in that case it should be pretty easy to confirm whether the
proposal can be implemented; if nothing else, Plaugher can make the
needed modifications to his own library, and determine whether they
work. Since his library is fairly popular, that also suggests that
there's a reasonable amount of existing experience with how to use a
library that's not too different from the final proposal.

Let's see... a POPULAR, PROVEN library by a renowned C expert being
considered for inclusion into the standard? What! Blasphemy! Right JN?

 

[MikeP]

As POSIX is already an international standard intended to provide a
Portable Operating System Interface, and therefore designed
specifically to provide portability, wouldn't it make sense if the
new C standard simply referenced this widely established standard
instead of designing yet another redundant set of interfaces intended
to duplicate (or triplicate) already existing APIs? Refusing to
reference existing standards due to pressure from a single platform
which is sold by a single vendor doesn't make sense.

So your point is that something by some standards organization should
always prevail over free enterprise? Standards are "old and stodgy"/"not
where the action is". Why implement obsolescence rather than embrace
state of the art? (I get the feeling that JN is a wannabe in that space
but cannot compete in it: if only the committee would give him their
blessing, then he would be able to play with the big boys. Do I have you
figured out yet JN?).

 

[MikeP]

I'm agnostic about whether adding threading to the C
standard was a good idea, but I can certainly see why it might be
desirable to have a threading API that can be used on both Windows
and POSIX systems.

Let's see.. the POSIX/Unix crowd has their threading API already and the
Windows crowd has theirs, and you are making the assumption that
something that works on both platforms is going to be liked/used by
either of those groups, even knowing that the approaches are different?
What are the chances!

Should the C standard library recognize threads? Yes. Should it provide a
whole API? Questionable.

 

[MikeP]

You didn't understand what I said. The reason why it is irrelevant to
compare similarities between both APIs is that, 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"

Would that be the final appearance of C on the Windows stage then? "C:
exit stage left please, and don't let the curtain call kick your ass on
the way out."

Then the C standard would be leaner, the standardization process
would be simpler and, most importantly, the relevant implementation
details could be cleanly separated from each other.

Better yet, dump all libraries from the C standard (they are crappy
anyway). Then the standard language and process becomes as lean as can be
and let's the committee FOCUS on the minimal support the language needs
to provide while allowing opportunities to vendors for innovation. (Maybe
then even JN could offer something up and he'd stop hissying! Maybe even
I would dust-off and polish-up some old C code I have laying around in
the basement (just to spite JN of course ;-)) ).

 

[Ian Collins]

So *all* types are lock-free? Likewise, all functions are banana-free.
And no structures have any hint of purple.

If the implementation chooses, yes

 

[MikeP]

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.

Would it be fair though to give one company such preference when there
are others chomping at the bit to play in that arena?

 

[MikeP]

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.

Or maybe it was just to Unixy/Ugly?

Now, by intentionally neglecting a widely adopted international
standard

Presumption of technical merit based upon... what? Time in grade?
Connections? Politics? Voting? You seem to be absurdly arguing.

for a threading API for the C which which already exists for
over a decade,

You are arguing against yourself with that point, for old is old, not
necessarily good, and likely obsolete.

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

But forcing an existing standard is technical and OK?

and instead caused by nothing
more than a single company's refusal to respect, let alone follow
standards.

But I thought the role of the committee and the standard was to codify
existing practice and is therefore the follower, not the leader. IOW, a
glorified secretary!

 

[MikeP]

"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.

Nor does creating a new API mean malicious intent.

 

[MikeP]

Where do you base that claim?



What? Do you even know what you are saying? For example, do you
actually know what the term "unix-like" refers to? Because even
windows fits the description of a "unix-like" system.

Not to developers. Not to all or even most, anyway.

You see, a unix-like system is a system which conforms to some but
not all the requirements stated in the single unix specification.

He said "Unix-like", and I think he meant by that: "Ugly like Unix".

This means that if some OS happens to offer support for pthreads then
it automatically enters the category of a unix-like system.

Not to developers.

Knowing
this, your comment boils down to "pthreads was designed for systems
which may use pthreads". Do you understand how silly this is?

Your tangent/strawman is non sequitor.

 

[MikeP]

Not only windows, a large number of RTOS (all that I use) have a POSIX
API. So I agree the statement is silly.

Not silly at all if he meant what I thought he meant. I think you two may
have not comprehended what he meant. Please clarify what you meant
Lawrence.

 

[MikeP]

Not true. Unnamed objects can be shared with child processes under
the correct circumstances.

OK. Then I should have wrote: "Unnamed synch objects are GENERALLY
intra-process" (or some such). (I should have not included additional
thoughts and stopped at the first carriage return perhaps).

Alternatively, and more generally, you can
use DuplicateHandle on an unnamed object and create a (new) handle to
that object for another process to use.

Sounds like a roundabout way of doing the same thing as naming an object
though.

Anyway, my point was that they are not NECESSARILY system-wide, and your
statement implied the opposite. You maybe should have said something
like: "Most of the synchronization objects in Windows CAN BE system
wide". (I would have used "inter-process" some way instead of "system
wide").

 

[Shao Miller]

I agree with MikeP on that point and would also suggest that Microsoft
doesn't have a "pathological reaction to open standards" nor a "need to
artificially hinder anything remotely related to portability."

Microsoft has done a lot of stuff. Some of that stuff fits with other
stuff, some of it doesn't. Probably all computer stuff can't fit
together nicely.

Just as a tiny example, it is common in Windows to see a TYPE_NAME and a
FunctionThatDoesSomething(). That's been that way for a good while.
That alone means pthreads don't fit "nicely."

But... I didn't see anything but the above quotations in your response,
Mr. R. Wessel. What happened?

 

[Shao Miller]

I hypothesize that SOME of the Win32 is built on top of native, but not
ALL or even MOST of it. The low-level native has to exist for capability
or performance reasons, but once enough code is laid down to work at a
higher level of abstraction, and when one can, one does (they do),
surely. (By "built on top of" I mean, "implemented in terms of",
actually).

You are correct. There is no restriction that the Windows API libraries
cannot depend on other Windows API libraries; the "Portable Executable
and Common Object File Format" (for .EXEs, .DLLs, and others) is the
same, regardless of subsystem. The "basest" of the Windows API
libraries depend on the "native" API, certainly.

Whatever the library that is called upon, the environment had better be
prepared to support it.

Pre-boot programs (OS loader, SCSI driver, etc.)
HAL & Kernel
- Drivers (kernel-land)
- Windows subsystem (kernel-land minority)
- Native-mode programs (user-land)
- Windows subsystem (user-land majority)
- Windows programs (common)
- POSIX subsystem (uncommon, user-land)
- POSIX programs (uncommon)

You can have a Windows XP system with 0 Windows (as in Windows API)
components; strictly POSIX. The more environments, the merrier!

 

[Rui Maciel]

Let's see... a POPULAR, PROVEN library by a renowned C expert being
considered for inclusion into the standard? What! Blasphemy! Right JN?

I don't believe that the pthreads API is not popular, proven nor developed
by C experts. Adding to this, the pthreads API has been an international
standard for over a decade, something which Dinkumware is not. If we are
discussing a standardization process then ignoring an already established
international standard while imposing a specific proprietary library which
tries to duplicate the features already covered by that international
standard then although it isn't blasphemy it sure isn't far from it. At
least in what concerns the standardization process it does look a lot like
incompetence, if not worse. And this doesn't bode well for this C201x
standardization effort.


Rui Maciel

 

[Rui Maciel]

So your point is that something by some standards organization should
always prevail over free enterprise? Standards are "old and stodgy"/"not
where the action is". Why implement obsolescence rather than embrace
state of the art?

Please demonstrate where exactly the pthreads API is obsolete and how
dinkumware's wrapper is superior to it.


Rui Maciel

 

[Rui Maciel]

Let's see.. the POSIX/Unix crowd has their threading API already and the
Windows crowd has theirs

Not quite. The only thing that stops a OS project from adding support for
pthreads is their unwillingness to do so. Regarding Microsoft, they already
provide suppoprt for pthreads. Therefore, this isn't a matter of
"POSIX/Unix crowd" Vs "Windows crowd". This is a matter of a widely
established and adopted international standard Vs an API taken from some
proprietary library. And when defining an international standard,
intentionally neglecting established international standards in favour of
some proprietary code is not a good thing.


Rui Maciel

 

[jacob navia]

Le 08/07/11 13:42, Rui Maciel a écrit :

I don't believe that the pthreads API is not popular, proven nor developed
by C experts. Adding to this, the pthreads API has been an international
standard for over a decade, something which Dinkumware is not. If we are
discussing a standardization process then ignoring an already established
international standard while imposing a specific proprietary library which
tries to duplicate the features already covered by that international
standard then although it isn't blasphemy it sure isn't far from it. At
least in what concerns the standardization process it does look a lot like
incompetence, if not worse. And this doesn't bode well for this C201x
standardization effort.


Rui Maciel

Not only that all interfaces are exactly the same as Dinkum's, the
specifications of the proposed standard are almost identical word for
word to the documentation of Dinkum's!

I still do not understand why Dinkum's doesn't sue because of
copyright infringement.