Harbison says "volatile" necessary for MT programming!
Doug Harrison
volatile is necessary for MT programming. It specifically invokes the
name of a well-known author of C programming books, Sam Harbison, so
check it out:
volatile: the great debate
http://www.flounder.com/volatile.htm
Here's an excerpt:
<q>
I decided to see what a true expert says.
I consulted with Dr. Sam Harbison, co-author of the highly-respected
book C: A Reference Manual. It is now in its fifth edition.
...
He has given me permission to print his response to my question to
him. I am reproducing the email in its entirety below.
If you don't want to read the whole thing, the summary is this: one of
the world's experts on the C language says that volatile is necessary
in a multithreaded environment. Not sufficient, but necessary. So in
this case, it is no longer my "opinion", as some easy-to-discredit
mere ex-academic; this is the opinion of someone whose credentials are
absolutely impeccable. So make your own decision as to who knows more
here.
</q>
That page is a response to my trying for many months to dissuade this
guy from preaching that every variable accessed by multiple threads
must be declared "volatile", even when all access occurs under the
protection of a mutex. This message is representative of what I've
said to him:
http://groups.google.com/groups?selm=h2evrvkjb2a0r69pp4j0280ibegttvvm9u%404ax.com
I've asked him over and over to prove his claims or disprove mine; his
response has been to ignore those requests and instead present new
claims and appeals to authority. Now, he thinks he has a definitive
answer from a "true expert", an answer I believe doesn't even properly
address the question. I'd be interested to hear the group's views on
this.
--
Doug Harrison
d...@mvps.org
David Butenhof
> Here's a link to a brand spankin' new web page which explains why
> volatile is necessary for MT programming. It specifically invokes the
> name of a well-known author of C programming books, Sam Harbison, so
> check it out:
Well, this is all incorrect and grossly misleading. I'd like to write this
without any negative reflection on the authors, who probably mean well, but
I can't help but laugh when an article starts with an enormous laundry list
of irrelevant "credentials" clearly designed to make it seem they know what
they're talking about... when it's obvious they don't.
But the point is really that their entire argument and position is
completely irrelevant. These experts aren't so much "wrong" as they are
arrogant, short-sighted, and narrow-minded.
The fundamental fallacy is that they're reading a specification (ANSI C)
that has no support for threads, and saying, "Gee, look, this specification
doesn't support threads. Well, the closest we can come to working with any
form of asynchronous operation is to use volatile, so let's say that." This
discovery, however clever it might seem to them, is ancient history: we
went through all that more than 15 years ago.
They're missing the fundamental point that ANSI C doesn't support threads.
Period. And you can't MAKE it support threads (even they admit that
volatile isn't "sufficient") without CHANGING or ADDING to it. You simply
CANNOT have purely portable strict ANSI C code that works in threads. It's
not possible. It's meaningless.
Instead, one writes POSIX 1003.1c-1995 code, (or "UI thread" code, or even
Win32 threaded code), which is BASED ON ANSI C (but is NOT ANSI C), and
provides ON TOP OF ANSI C support for multithreaded programming that DOES
NOT require volatile (and in fact cannot benefit from use of volatile).
Such code, to redundantly reiterate yet again, is NOT, repeat, NOT strict
ANSI C. Its behavior cannot be explained, described, or reasoned about
simply in terms of the ANSI C specification, no matter how expert one might
be in the nuances of that standard. Again, (yes, once again redundantly
reiterating), THREADED CODE IS NOT ANSI C.
And that's really all there is to it.
To put this another way, it's perfectly legal for an ANSI C compiler to
apply optimizations that would break threaded code by invalidating data
visibility requirements. (Though in practice expert compiler developers
tell me such optimizations are extraordinarily difficult to exploit in
practice, and at least as of several years ago nobody was aware of anyone
who had succeeded.) But such a compiler, while it might be 100% conformant
to ANSI C requirements, and might seem "really cool" from a myopic ANSI C
point of view, is NOT a POSIX conforming compiler, and cannot be used for
threaded programming. "Correct" is often a relative statement. (As Obi Wan
put it, "Many of the truths we cling to depend greatly on our point of
view.")
These experts are outside their area of expertise, and apparently can't see
it. That's sad; but worse, their stubbornness is going to hurt a lot of
people who blindly believe them simply because of their claims to
"expertise"...
Which is really a lot like taking my investment advice on the basis that I'm
an acknowledged expert in threaded programming.
--
/--------------------[ David.B...@hp.com ]--------------------\
| Hewlett-Packard Company Tru64 UNIX & VMS Thread Architect |
| My book: http://www.awl.com/cseng/titles/0-201-63392-2/ |
\----[ http://homepage.mac.com/dbutenhof/Threads/Threads.html ]---/
Alexander Terekhov
David Butenhof wrote:
[...]
> Which is really a lot like taking my investment advice on the basis that I'm
> an acknowledged expert in threaded programming.
After ~50% correction in stock price, SCO ("the owner of the UNIX®
operating system and a leading provider of UNIX-based solutions")
yesterday announced stock buyback program, BTW. ;-) ;-)
regards,
alexander.
Loic Domaigne
> Here's a link to a brand spankin' new web page which explains why
> volatile is necessary for MT programming. It specifically invokes the
> name of a well-known author of C programming books, Sam Harbison, so
[snip]
> I've asked him over and over to prove his claims or disprove mine; his
> response has been to ignore those requests and instead present new
> claims and appeals to authority. Now, he thinks he has a definitive
> answer from a "true expert", an answer I believe doesn't even properly
> address the question. I'd be interested to hear the group's views on
> this.
I'm definitively _not_ recognized as a world-class expert in the C
language, nor MT stuff ... so that's just a 2 Cents on this...
If I got it right, the point was made that (at least theoritically), a
compiler could optimize the code in such way that the mutex protection is
rendered useless. Like in the short example:
lock(mutex);
something = x;
unlock(mutex);
whatever = something; (***)
could be optimized as:
lock(mutex);
unlock(mutex);
something = x;
whatever = something;
IMHO the line (***) has a serious design flaw. You can't copy a variable
that is shared among thread without proper synchronization, because you
might violate memory visibility rule... The optimization performed by the
compiler is in a sense fine, since it has the same flaw as the original
code...
I can't judge whether the claim is theoritically founded or not...
But my feelings - and that's just a feeling, not a proof - is that well
designed program (i.e. that insures correct memory visibility of shared
variables among the threads by proper synchronization) shouldn't need
volatile.
Sure an conter-example (that compiles!), even academic one, is welcome...
Regards,
Loic.
--
Article posté via l'accès Usenet http://www.mes-news.com
Accès par Nnrp ou Web
Giancarlo Niccolai
>
> But the point is really that their entire argument and position is
> completely irrelevant. These experts aren't so much "wrong" as they are
> arrogant, short-sighted, and narrow-minded.
>
> They're missing the fundamental point that ANSI C doesn't support threads.
> Period. And you can't MAKE it support threads (even they admit that
> volatile isn't "sufficient") without CHANGING or ADDING to it. You simply
> CANNOT have purely portable strict ANSI C code that works in threads. It's
> not possible. It's meaningless.
>
I have but a tenth of the expertize of dr. Butenhof in this field, maybe
less, yet I feel I am far more expert that the "professor" who replied the
emails of mr. Newcomer, and I am light years before that person itself. The
sole fact that he is talking about
lock();
something = x;
unlock();
whathever = something;
is a so basic error that even the ppl. that enters in this NG and claims to
be a newbe is able to recognize.
I would request you (mr. Harrison) to invite mr. Newcomer to join our NG, so
he can add to his expertize something related to multithreading.
Sometimes ago we argued about the fact that multithreading programming adds
a new complexity dimension with respect even to multiprocess (concurrent)
programming, even if some problems can look similar in the two worlds (Mr.
Butenhof and me agreed on that). So, even if I don't even want to contest
his claim about being qualified
"""
to offer any opinions on optimizing compiler technology, caching technology,
or apparently anything much dealing with concurrency.
(J.M. Newcomer)
"""
I sustain that knowing concurrency (and just that), can be even misleading
in the consideration of multithreading added levels of complexity.
So, please, invite him here so he can learn something that its not in his
expertise fields (of which, btw, I do not claim to be an expert in).
Giancarlo Niccolai.
P.S.
You can learn strategy rules in a week.
To master it, a life is not enough.
Sun Tsu - the art of war.
Hovik Melikyan
"Loic Domaigne" <loic...@gmx.net> wrote in message
news:mW.HuE...@mes-news.com...
>
> If I got it right, the point was made that (at least theoritically), a
> compiler could optimize the code in such way that the mutex protection is
> rendered useless. Like in the short example:
>
> lock(mutex);
> something = x;
> unlock(mutex);
> whatever = something; (***)
>
> could be optimized as:
>
> lock(mutex);
> unlock(mutex);
> something = x;
> whatever = something;
>
From my experiments with GCC, MSVC and BCC: neither of them optimize it that
way if x is global, which is natural, since the compiler has no idea on what
unlock() is doing (maybe modifying x?). They however can do really anything
with x, 'something' and 'whatever' if they are local, which doesn't make
much sense in this case.
> The optimization performed by the compiler is in a sense fine <...>
As you can see it's not.
--
HM
Loic Domaigne
> From my experiments with GCC, MSVC and BCC: neither of them optimize
> it that way if x is global, which is natural, since the compiler has no
> idea on what unlock() is doing (maybe modifying x?). They however can do
> really anything with x, 'something' and 'whatever' if they are local,
> which doesn't make much sense in this case.
> > The optimization performed by the compiler is in a sense fine <...>
>
> As you can see it's not.
Pls. don't cut the most important context of the sentence. I said:
You can't expect a compiler to produce an equivalent, POSIXLY correct,
code from a POSIXLY broken one... So even if in *theory* such optimization
could take place, we should not blame the compiler, but the programmer...
The fact that in praxis such optimization never happens (or seems to)
just adds more fun to the whole discussion ;-)
Regards,
Loic.
------
"On two occasions I have been asked [by members of Parliament], 'Pray, Mr.
Babbage, if you put into the machine wrong figures, will the right answers
come out?' I am not able rightly to apprehend the kind of confusion of
ideas that could provoke such a question." - Charles Babbage
Nathan J. Williams
> If I got it right, the point was made that (at least theoritically), a
> compiler could optimize the code in such way that the mutex protection is
> rendered useless. Like in the short example:
The point that changes this, which David Butenhof explained, is that
you can't reasonably analyze a threaded program in a pure ANSI
environment. Or, put another way, the compiler (really, the entire
development environment: compiler, headers, libraries, etc) has to be
made thread-aware, and has to know that reordering around mutex
operations isn't permitted.
Often this is done by using compiler extentions to mark the mutex
functions specially, or by coding them inline and including, with
similar extensions, memory barrier markers. Sometimes it depends on
knowing that the compiler for a particular environment isn't agressive
about optimizing around function calls.
- Nathan
Loic Domaigne
> > If I got it right, the point was made that (at least theoritically), a
> > compiler could optimize the code in such way that the mutex protection
> > is rendered useless. Like in the short example:
AGAIN, my point was: even if the compiler didn't optimize the code,
because it knows that it is not allowed to, the example would have been
broken anyway.
Mind you, but "If 2 is equal to 1, then I am the President of USA"
evaluates to TRUE ;-)
[ Proof: The US President and me are two different persons, but since
2=1, we are the same person. So I'm the President of USA. ]
> The point that changes this, which David Butenhof explained
[snip]
> Often this is done by using compiler extentions to mark the mutex
> functions specially, or by coding them inline and including, with
> similar extensions, memory barrier markers. Sometimes it depends on
> knowing that the compiler for a particular environment isn't agressive
> about optimizing around function calls.
Yup... ('-pthread' and the likes...)
David Schwartz
> compiler could optimize the code in such way that the mutex protection is
> rendered useless. Like in the short example:
> lock(mutex);
> something = x;
> unlock(mutex);
> whatever = something; (***)
> could be optimized as:
> lock(mutex);
> unlock(mutex);
> something = x;
> whatever = something;
His argument would have to be that the *only* way to stop this from
happening is to make 'something' or 'x' or both volatile, otherwise volatile
isn't necessary. As a stupid hypothetical counter-example, suppose I was
coding to the FEETHREAEDS standard that specified that every variable in the
entire program was to be treated by the compiler as if it was volatile. Then
I wouldn't need the volatile keyword, would I?
DS
David Schwartz
"Hovik Melikyan" <ho...@melikyan.com> wrote in message
news:c2q2et$208jrh$1...@ID-207516.news.uni-berlin.de...
> From my experiments with GCC, MSVC and BCC: neither of them optimize it
> that
> way if x is global, which is natural, since the compiler has no idea on
> what
> unlock() is doing (maybe modifying x?). They however can do really
> anything
> with x, 'something' and 'whatever' if they are local, which doesn't make
> much sense in this case.
Though it really isn't relevant to the argument, the reason this isn't a
problem as a practical matter is that any way another thread could modify a
variable the 'lock' or 'unlock' functions could too. So, as long as the
compiler has no special knowledge of the 'lock' or 'unlock' functions to teh
contrary, it must assume they can modify anything another thread could
modify.
DS
David Schwartz
"Nathan J. Williams" <nat...@mit.edu> wrote in message
news:mtuhdwv...@contents-vnder-pressvre.mit.edu...
> Often this is done by using compiler extentions to mark the mutex
> functions specially, or by coding them inline and including, with
> similar extensions, memory barrier markers. Sometimes it depends on
> knowing that the compiler for a particular environment isn't agressive
> about optimizing around function calls.
It's done just by keeping the compiler ignorant of what the mutex
functions do. For all the compiler knows, both 'lock' and 'unlock' could
access a volatile variable. So neither of them can be re-ordered around.
Consider:
lock();
x++;
unlock();
If 'lock' or 'unlock' could touch 'x', then the 'x++' can't be moved
around the 'lock' or 'unlock'. If another thread could touch 'x', then so
could the 'lock' or 'unlock' functions.
So it's most commonly done by keeping the compiler ignorant.
DS
Doug Harrison
>Well, this is all incorrect and grossly misleading. I'd like to write this
>without any negative reflection on the authors, who probably mean well, but
>I can't help but laugh when an article starts with an enormous laundry list
>of irrelevant "credentials" clearly designed to make it seem they know what
>they're talking about... when it's obvious they don't.
Oh man, I see what you mean. That long bullet list at the start of
Joseph M Newcomer's web page wasn't even there when I posted my
message last night, and there was a much smaller picture of the
Harbison book. Sadly, the technical content has remained the same.
Thanks very much for your comments.
--
Doug Harrison
d...@mvps.org
Doug Harrison
>I have but a tenth of the expertize of dr. Butenhof in this field, maybe
>less, yet I feel I am far more expert that the "professor" who replied the
>emails of mr. Newcomer, and I am light years before that person itself. The
>sole fact that he is talking about
>
>lock();
>something = x;
>unlock();
>whathever = something;
>
>is a so basic error that even the ppl. that enters in this NG and claims to
>be a newbe is able to recognize.
Yep. I only wish Joseph M Newcomer had posted something like that all
those times I asked him to back up his claims. Then we could have had
a real discussion. Instead, he repeatedly refused to back up his
claims with examples, he refused to comment directly on my detailed
arguments, he went off on various irrelevant tangents, and he tried
again and again to appeal to what I guess he perceives as higher and
higher "authorities", including himself. :) I posted here only because
he had exhausted my lines of argument; there was literally nothing
left I could say to the guy.
>I would request you (mr. Harrison) to invite mr. Newcomer to join our NG, so
>he can add to his expertize something related to multithreading.
Will do.
--
Doug Harrison
d...@mvps.org
John Hickin
>
>
> The fact that in praxis such optimization never happens (or seems to)
> just adds more fun to the whole discussion ;-)
>
You might (unhappily) discover that it could be related to the amount of
inlining used throughout the source code. And now what the compiler thinks
that is can optimize is a function of what it thought should be inlined.
These two computations may be implemented in the compiler by different
teams, at different times, and thay may interact in strange ways.
Just more fun :^)
Regards, John.
Michael Furman
"David Butenhof" <David.B...@hp.com> wrote in message
news:4050...@usenet01.boi.hp.com...
> [...]
> ... point of view, is NOT a POSIX conforming compiler, and cannot be used
for
> threaded programming.
Just curious: do you believe that "threaded programming" is equal to
"threaded programming using POSIX conforming compiler & library"?
Michael Furman
David Schwartz
"Michael Furman" <Michae...@Yahoo.com> wrote in message
news:c2t8ar$20ltus$1...@ID-122417.news.uni-berlin.de...
That's not the point. Harbison is saying "volatile" is necessary. If we
can produce one situation in which "volatile" is not used but the code is
still guaranteed to work, then "volatile" is *not* necessary.
DS
Michael Furman
"David Schwartz" <dav...@webmaster.com> wrote in message
news:c2tcg9$jid$1...@nntp.webmaster.com...
>
> "Michael Furman" <Michae...@Yahoo.com> wrote in message
> news:c2t8ar$20ltus$1...@ID-122417.news.uni-berlin.de...
>
> > "David Butenhof" <David.B...@hp.com> wrote in message
> > news:4050...@usenet01.boi.hp.com...
> >> [...]
> >> ... point of view, is NOT a POSIX conforming compiler, and cannot be
used
> > for
> >> threaded programming.
>
> > Just curious: do you believe that "threaded programming" is equal to
> > "threaded programming using POSIX conforming compiler & library"?
>
>
> That's not the point. Harbison is saying "volatile" is necessary. If
we
No, that is not. It is just a question - I am trying to understand what
David Butenhof
intended to say.
Sean Burke
Well, there's always old-school threaded programming,
with setjmp(), longjmp(), and a bit of duct-tape. ;-)
-SEan
Casper H.S. Dik
> It's done just by keeping the compiler ignorant of what the mutex
>functions do. For all the compiler knows, both 'lock' and 'unlock' could
>access a volatile variable. So neither of them can be re-ordered around.
.. or a non volatile variable for that matter.
In fact it can be argued that any modification of access to a variable
which is not on the stack cannot be hoisted across function calls
unless the compiler has complete knowledge of the function.
(Even variables local and static to the function can be modified
if a recursive call to the function is attempted)
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Hovik Melikyan
>
> "Nathan J. Williams" <nat...@mit.edu> wrote in message
> news:mtuhdwv...@contents-vnder-pressvre.mit.edu...
>
> > Often this is done by using compiler extentions to mark the mutex
> > functions specially, or by coding them inline and including, with
> > similar extensions, memory barrier markers. Sometimes it depends on
> > knowing that the compiler for a particular environment isn't agressive
> > about optimizing around function calls.
>
>
> It's done just by keeping the compiler ignorant of what the mutex
> functions do. For all the compiler knows, both 'lock' and 'unlock' could
> access a volatile variable. So neither of them can be re-ordered around.
>
Consider hardware support for mutexes at CPU level (why not?). Lock() and
unlock() are fully inlined and produce just a few CPU instructions. AFAIK
there is no such thing like volatile function, but it might be convenient to
allow marking mutex functions as volatile in this case, meaning the compiler
should invalidate all local optimizations at the point of calling the
function.
--
HM
David Schwartz
"Doug Harrison" <d...@mvps.org> wrote in message
news:skov40hc4rk4bco0a...@4ax.com...
> I've asked him over and over to prove his claims or disprove mine; his
> response has been to ignore those requests and instead present new
> claims and appeals to authority. Now, he thinks he has a definitive
> answer from a "true expert", an answer I believe doesn't even properly
> address the question. I'd be interested to hear the group's views on
> this.
I have corresponded with him through email as well. Willful ignorance
cannot be fixed. His rudeness has been escalating and I'm starting to feel
that I won't be able to prevent myself from following suit.
What's so amusing is that it's his experience that's specifically
leading him astray. For example, he says, "I've been dealing with reality
for close to 30 years now, using languages that had no formal concurrency to
write concurrent programs." Well, yeah, maybe if there was no way that was
guaranteed to produce working code, 'volatile' might be better than nothing.
But it's been a long time since it was impossible to write multi-threaded
that was as guaranteed to work as strictly-conforming C99 programs are.
DS
David Butenhof
On one hand, my note did also specifically recognize Win32 threads, though
you didn't choose to quote that part. On the other hand, I was involved in
defining "POSIX threads", have implemented it, and use it regularly; and
its semantics are better defined than Win32, more formally defined, and its
an open standard. Furthermore, I have no interest in or respect for
Microsoft or its proprietary interfaces.
So take your pick. ;-)
David Butenhof
Those definitely are NOT threads! They're co-routines. And the most
important distinction is that co-routines cannot run in parallel; which
means that hardware memory visibility issues are irrelevant. However,
unless you've got some specification that requires unusual behavior from
the compiler with respect to setjmp or longjmp (which is possible, of
course, but doesn't currently exist), you WOULD have to use volatile to
ensure that you don't lose register caches of memory variables across a
setjmp(). That IS one of the defined characteristics and uses of the ANSI C
language volatile keyword. Of course, if those bits stick to the duct tape
across the "context switch", you might be OK. ;-)
Alexander Terekhov
David Butenhof wrote:
[...]
> > Well, there's always old-school threaded programming,
> > with setjmp(), longjmp(), and a bit of duct-tape. ;-)
>
> Those definitely are NOT threads! They're co-routines.
Not even that. They're prehistoric exceptions!
http://www.codesourcery.com/cxx-abi/abi-eh.html
<quote>
_UA_FORCE_UNWIND
During phase 2, indicates that no language is allowed to
"catch" the exception. This flag is set while unwinding
the stack for longjmp
<quote>
Well,
http://www.codesourcery.com/archives/c++-pthreads/msg00126.html
regards,
alexander.
Michael Furman
> Michael Furman wrote:
> [...]
> > "David Butenhof" <David.B...@hp.com> wrote in message
> > news:4050...@usenet01.boi.hp.com...
> >> [...]
> >> ... point of view, is NOT a POSIX conforming compiler, and cannot be
used
> >> for threaded programming.
> >
> > Just curious: do you believe that "threaded programming" is equal to
> > "threaded programming using POSIX conforming compiler & library"?
>
> On one hand, my note did also specifically recognize Win32 threads, though
> you didn't choose to quote that part. On the other hand, I was involved in
> defining "POSIX threads", have implemented it, and use it regularly; and
> its semantics are better defined than Win32, more formally defined, and
its
> an open standard. Furthermore, I have no interest in or respect for
> Microsoft or its proprietary interfaces.
Thanks for answer.
>
> So take your pick. ;-)
I do ;-):
So, I interpret your answer as you believe that "threaded programming" is
equal to
"threaded programming using POSIX conforming compiler & library" and may be
in worst case also Win32 threads... I believe that there are (and could be)
other threads,
but it does not matter. What I want to say that
"... is NOT a POSIX conforming compiler, and cannot be used for threaded
programming"
is not true. I believe you wanted to say "... is NOT a POSIX conforming
compiler, and cannot
be used for POSIX threaded programming": MSVC compiler is not POSIX
conforming,
but, I believe, it can be used for Win32 threaded programming (though it
worse defined etc.).
Regards,
Michael Furman
Michael Furman
> Sean Burke wrote:
>
> > "Michael Furman" <Michae...@Yahoo.com> writes:
> >
> >> "David Butenhof" <David.B...@hp.com> wrote in message
> >> news:4050...@usenet01.boi.hp.com...
> >> > [...]
> >> > ... point of view, is NOT a POSIX conforming compiler, and cannot be
> >> > used
> >> for
> >> > threaded programming.
> >>
> >> Just curious: do you believe that "threaded programming" is equal to
> >> "threaded programming using POSIX conforming compiler & library"?
> >
> > Well, there's always old-school threaded programming,
> > with setjmp(), longjmp(), and a bit of duct-tape. ;-)
>
> Those definitely are NOT threads! They're co-routines. And the most
> important distinction is that co-routines cannot run in parallel; which
> means that hardware memory visibility issues are irrelevant. However,
> unless you've got some specification that requires unusual behavior from
> the compiler with respect to setjmp or longjmp (which is possible, of
> course, but doesn't currently exist), you WOULD have to use volatile to
> ensure that you don't lose register caches of memory variables across a
> setjmp(). That IS one of the defined characteristics and uses of the ANSI
C
> language volatile keyword. Of course, if those bits stick to the duct tape
> across the "context switch", you might be OK. ;-)
That is not necessarily co-rutines - it depends of duct-tape ;-).
It could be what I would call now as non-preemtive threads - if there is a
scheduler that
deside which "thread" to execute next after the current one have voluntarily
lost control. Yes they can't run in parallel on 2 or more CPUs - but if
there one CPU
they are in many aspects similar to the normal thread.
Michael Furman
David Butenhof
> I believe you wanted to say "... is NOT a POSIX conforming compiler, and
> cannot be used for POSIX threaded programming": MSVC compiler is not POSIX
> conforming, but, I believe, it can be used for Win32 threaded programming
> (though it worse defined etc.).
Sigh. Some people just can't stop nit-picking. (And yeah, I'm fully aware
that I'm one of them, but that's not relevent here because YOU are
nit-picking ME. ;-) )
Remember this was not an argument about "POSIX vs Win32" until you turned it
around. Win32 and MSVC have no status as a formal standard or official
extension of ANSI C semantics, even aside from the fact that they don't
personally interest ME in any way. POSIX, on the other hand, is an
international (ISO/IEEE) standard that formally and explicitly extends ANSI
C semantics in well-defined ways.
I was arguing that this guy's prattling about volatile is irrelevent
specifically because he's applying a standard (ANSI C) where it explicitly
and clearly does not belong, and where a formalized international standard
has already (long since) addressed the problem he's trying to hack around.
He may or may not care about Microsoft's informal and ad-hoc implementation
of Win32 and MSVC, but if he won't recognize the validity and scope of
POSIX (ISO/IEC 9945-1), then he's a completely hopeless case in any
possible terms.
When you argue with a lawyer, you'd better be able to speak legalese. When
you argue with a standards hack, you'd better speak standardese. I'm armed
and dangerous. ;-)
David Butenhof
>> Those definitely are NOT threads! They're co-routines. >
>
> That is not necessarily co-rutines - it depends of duct-tape ;-).
> It could be what I would call now as non-preemtive threads
Sure, I was using the term "co-routine" loosely. The point is that they're
not "threads" in any useful sense. For example, you can't switch between
threads on a pagefault; or even explicit I/O blocking without complicated,
error-prone, and at best extremely limited hackery. They are not
INDEPENDENT execution contexts, even ignoring the fact that they cannot run
in parallel.
This is the kind of junk that was barely acceptable 15 years ago when there
WERE no real thread packages; but shouldn't tempt anyone now. ;-)
Michael Furman
> Michael Furman wrote:
>
> >> Those definitely are NOT threads! They're co-routines. >
> >
> > That is not necessarily co-rutines - it depends of duct-tape ;-).
> > It could be what I would call now as non-preemtive threads
>
> Sure, I was using the term "co-routine" loosely. The point is that they're
> not "threads" in any useful sense. For example, you can't switch between
> threads on a pagefault; or even explicit I/O blocking without complicated,
> error-prone, and at best extremely limited hackery. They are not
> INDEPENDENT execution contexts, even ignoring the fact that they cannot
run
> in parallel.
IMO you use all wards very "losely" - so it make any useful discussion
almost
impossible. Now it is "any useful sense"!
Besides that you are correct about page fault, but not correct about
explicit I/O blocking. In non-preemtive model thread switching can occur
at any "synchronous" event - i.e. when thread calls some system function
e.g. I/O, synchronization, enqueue/dequeue etc.
the are partially INDEPENDENT execution contexts.
Michael Furman
Michael Furman
> Michael Furman wrote:
>
> > I believe you wanted to say "... is NOT a POSIX conforming compiler,
and
> > cannot be used for POSIX threaded programming": MSVC compiler is not
POSIX
> > conforming, but, I believe, it can be used for Win32 threaded
programming
> > (though it worse defined etc.).
>
> Sigh. Some people just can't stop nit-picking. (And yeah, I'm fully aware
> that I'm one of them, but that's not relevent here because YOU are
> nit-picking ME. ;-) )
I am not nit-picking. I would like (and tried) to participate in discussions
related
to threads, but it is impossible w/o using some exact definitions. If you
really believe
that it is wrong to use word "thread" for something different from POSIX
threads
(as I do) - I will deside either to use some different word or just shut up.
For example - can I call IBM370 OS subtasks (generated by macro "attach")
threads?
>
> Remember this was not an argument about "POSIX vs Win32" until you turned
it
> around. Win32 and MSVC have no status as a formal standard or official
> extension of ANSI C semantics, even aside from the fact that they don't
> personally interest ME in any way. POSIX, on the other hand, is an
> international (ISO/IEEE) standard that formally and explicitly extends
ANSI
> C semantics in well-defined ways.
Ooo! So this group is only about things that are standardized and
interested
for you personally! Is it stated somewhere?
> I was arguing that this guy's prattling about volatile is irrelevent
> specifically because he's applying a standard (ANSI C) where it explicitly
> and clearly does not belong, and where a formalized international standard
> has already (long since) addressed the problem he's trying to hack around.
> He may or may not care about Microsoft's informal and ad-hoc
implementation
> of Win32 and MSVC, but if he won't recognize the validity and scope of
> POSIX (ISO/IEC 9945-1), then he's a completely hopeless case in any
> possible terms.
I did not say that he is correct - only that you are wrong!
>
> When you argue with a lawyer, you'd better be able to speak legalese. When
> you argue with a standards hack, you'd better speak standardese. I'm armed
> and dangerous. ;-)
It is not comp.std.threads.
Michael Furman
Jonathan Adams
>
> I am not nit-picking.
It certainly looks like you are. Butenoff's original quote:
| To put this another way, it's perfectly legal for an ANSI C compiler
| to apply optimizations that would break threaded code by
| invalidating data visibility requirements. ... But such a compiler,
| while it might be 100% conformant to ANSI C requirements, and might
| seem "really cool" from a myopic ANSI C point of view, is NOT a
| POSIX conforming compiler, and cannot be used for threaded
| programming.
is pretty straight forward. If a compiler applies optimizations that
break the data visibility requirements *required* by threaded code,
it:
1) is not POSIX conformant, and
2) cannot be used for threaded programming
Both of which are true, unless you think that "threaded programming
with everything marked volatile" is a reasonable threaded programming
model. There is no implication (as I read it) that (2) is the result
of (1) -- instead, both (1) and (2) are true because the compiler is
breaking the memory model needed for reliable threaded programming,
POSIX or not.
- jonathan
Patrick TJ McPhee
Jonathan Adams <jonath...@ofb.net> wrote:
[...]
% Both of which are true, unless you think that "threaded programming
% with everything marked volatile" is a reasonable threaded programming
% model.
Keeping in mind that an ANSI C compiler can apply optimizations which
break multi-threaded code, even if everything is marked volatile.
--
Patrick TJ McPhee
East York Canada
pt...@interlog.com
SenderX
> break multi-threaded code, even if everything is marked volatile.
Assembler is key to portability, wrt retaining the integrity of your atomic
sequences.
David Butenhof
> "David Butenhof" <David.B...@hp.com> wrote in message
> news:4056...@usenet01.boi.hp.com...
>> Michael Furman wrote:
>>
>> >> Those definitely are NOT threads! They're co-routines. >
>> >
>> > That is not necessarily co-rutines - it depends of duct-tape ;-).
>> > It could be what I would call now as non-preemtive threads
>>
>> Sure, I was using the term "co-routine" loosely. The point is that
>> they're not "threads" in any useful sense. For example, you can't switch
>> between threads on a pagefault; or even explicit I/O blocking without
>> complicated, error-prone, and at best extremely limited hackery. They are
>> not INDEPENDENT execution contexts, even ignoring the fact that they
>> cannot run in parallel.
>
> IMO you use all wards very "losely" - so it make any useful discussion
> almost impossible. Now it is "any useful sense"!
I often use words casually when the distinctions are of no relevance to the
current discussion -- because that is a lot easier to write and to read.
But the value does somewhat depends on people being able to keep on topic.
> Besides that you are correct about page fault, but not correct about
> explicit I/O blocking. In non-preemtive model thread switching can occur
> at any "synchronous" event - i.e. when thread calls some system function
> e.g. I/O, synchronization, enqueue/dequeue etc. the[y] are partially
> INDEPENDENT execution contexts.
How do you switch on "synchronous events" in a "user mode" "thread"
"scheduler" based on setjmp/longjmp? With non-blocking I/O and select()?
There are enormous icebergs in your way, and holes you can drive a fleet of
supertankers through. For example, it doesn't work with any synchronization
aside from pipes or sockets, traditional UNIX select "lies" about any
file-oriented device (it's "always ready" even when it's really not), and
when you start to implement the chain of hackery you'll run into a long and
complicated set of more specific problems. We spent years trying to get
this right for DCE threads, and it's just not practical. (I won't even
argue whether it's "possible" -- in a perfect world it would be possible,
but also completely irrelevant.)
You're certainly welcome to disagree with me in any respect, though. Knock
yourself out.
David Butenhof
> "David Butenhof" <David.B...@hp.com> wrote in message
> news:4057...@usenet01.boi.hp.com...
>> Michael Furman wrote:
>>
>> Sigh. Some people just can't stop nit-picking. (And yeah, I'm fully aware
>> that I'm one of them, but that's not relevent here because YOU are
>> nit-picking ME. ;-) )
>
> I am not nit-picking.
Sorry, but yes you are. And you're not even picking real nits; you're
imagining them.
Once again, my principle interest and involvement is in the only
international formal standard for threading operations, which is also a
formally recognized ISO/IEC extension to the ANSI C language. Since the
issue of "ANSI C conformance" seems to be at the heart of these foolish
attempts to sell the use of "volatile", that also seems a particularly
appropriate response.
This isn't to say that SVR4.2 "UI" threads, or Win32 threads, or DCE
threads, or our own CMA threads, or anything else that's nonstandard or
"less standard" aren't "threads" -- merely that they don't have the same
legal standing in this context. "Thread" is a term that's been in generic
use for decades -- trying to pretend that it applies only to POSIX threads
would be silly and pointless. (And, incidentally, wrong.)
Aside from pure standards conformance issues, none of those distinctions
matter. On a Win32 system any compiler that will break threaded code using
mutexes, or critical sections, or even events for synchronization is
useless junk, and nobody will use it even it doesn't technically violate
any formal rules. The same is true for UI threads on Solaris, or CMA on
OpenVMS and Tru64 UNIX, or DCE threads anywhere it's still deployed. But
those are all pragmatic "quality of implementation" issues, and not
strictly relevant (and certainly weaker claims) against this sort of
attack.
Mark Piffer
> This isn't to say that SVR4.2 "UI" threads, or Win32 threads, or DCE
> threads, or our own CMA threads, or anything else that's nonstandard or
> "less standard" aren't "threads" -- ...
Well, it seems to me that the whole fuzz-about-volatile started
without the explicit naming of POSIX threads, at least the intention
of several of the pro-volatile arguments seemed to be made in the
notion of thread programming down at the bare metal; IOW, how are you
programming threads with nothing but the C compiler between you and
the machine? Following your interpretation of ANSI-C the answer is:
you can't; The problem I see: you will have to. We all know that there
are tons of small (embedded & other) systems out there being
programmed with pure C, some with an OS, some without, but surely most
of them with no support for threading. Threading and/or interrupts are
heavily employed on those systems however, but you insist that such
systems effectively can't be programmed because of the data integrity
problems of preemptive instruction flows in the absence of standards
like POSIX.
> Aside from pure standards conformance issues, none of those distinctions
> matter. On a Win32 system any compiler that will break threaded code using
> mutexes, or critical sections, or even events for synchronization is
> useless junk, and nobody will use it even it doesn't technically violate
> any formal rules.
How can one deduce that a compiler does "technically ok" but screws up
real-world applications? How can you guarantee correctness for the
next compiler version that you use on a seemingly-proven-correct code?
While I know your answers in advance (namely that all that is bad
engineering and such code was broken right from the beginning) I think
that this is a topic too important to be neglected - you are
surrounded by systems which try on MT and are programmed in pure C.
Mark
--
David Butenhof
>> Aside from pure standards conformance issues, none of those distinctions
>> matter. On a Win32 system any compiler that will break threaded code
>> using mutexes, or critical sections, or even events for synchronization
>> is useless junk, and nobody will use it even it doesn't technically
>> violate any formal rules.
> How can one deduce that a compiler does "technically ok" but screws up
> real-world applications? How can you guarantee correctness for the
> next compiler version that you use on a seemingly-proven-correct code?
> While I know your answers in advance (namely that all that is bad
> engineering and such code was broken right from the beginning) I think
> that this is a topic too important to be neglected - you are
> surrounded by systems which try on MT and are programmed in pure C.
I'm really not sure whether I should even try to reply, because it seems to
me that you're working really hard to miss the point.
Re-read my previous message -- the one to which you replied. Re-read the
paragraph you quoted up above.
"ANSI C" (or ISO/IEC C if you prefer) and C++ don't support threads. Period.
On any system that DOES support threads, any compiler that doesn't is
broken. If you're using a compiler that CLAIMS to support that system,
whether it's proprietary Win32 or standard POSIX, and they later "make a
change" that breaks LEGAL threaded code on that platform, it's a compiler
bug. No different from any other compiler bug, like performing an add
operation on the wrong register. Compiler bugs do happen, and sometimes the
effect on application code can be quite subtle -- but silly (and, worse,
ineffective) workarounds like 'volatile' completely miss the point, because
most often you're at best just reducing the chances that you'll detect the
remaining problems while you can still do something about them.
The real difference in this context, and the main reason I focus on POSIX,
is that the basis for a "thread-safe C compiler" within POSIX is explicit
and formalized. POSIX has legal/formal standing as an extension of ANSI C,
and the requirements on a conforming compiler are clear. You don't code
POSIX threaded programs with an "ANSI C" compiler -- you program with a
"POSIX" compiler. An "ISO/IEC C" conforming compiler is useless on any
threaded system if it performs optimizations that break threaded code. But
on a POSIX system it's easy to say "that's not a conforming compiler",
because it ought to be POSIX conforming, not merely ISO/IEC conforming. On
Win32, though, the same compiler would be "conforming" (to ISO/IEC C), but
"incompatible with Win32". Equally useless, but for reasons that might
perhaps be far more obvious to real programmers than to standards hacks.
(And note that there's no such thing as a "POSIX C++ compiler", so once you
move from C to C++ you have no such formal guarantees. In practice, this
doesn't matter because on each platform either the platform C++ compiler
DOES or [rarely] DOES NOT support programming with threads. You're now on
the UI or Win32 grounds instead of formalized POSIX, but who really cares?)
David Schwartz
"Mark Piffer" <sorryon...@yahoo.com> wrote in message
news:cce99527.04032...@posting.google.com...
> Well, it seems to me that the whole fuzz-about-volatile started
> without the explicit naming of POSIX threads, at least the intention
> of several of the pro-volatile arguments seemed to be made in the
> notion of thread programming down at the bare metal; IOW, how are you
> programming threads with nothing but the C compiler between you and
> the machine?
Answer: You cannot, except in a platform-dependent way that might work
with one version of the compiler and not the next. Period. This is true
whether or not you use 'volatile'.
> Following your interpretation of ANSI-C the answer is:
> you can't;
Bingo.
> The problem I see: you will have to.
Then you have two choices: You can use some standard or
platform-dependent mechanism that produces code that is guaranteed to work
or you can use any mechanism that just happens to work on your platform of
choice. (Notice the word 'volatile' doesn't appear in either of those
choices because it doesn't do either of those two things.)
> We all know that there
> are tons of small (embedded & other) systems out there being
> programmed with pure C, some with an OS, some without, but surely most
> of them with no support for threading.
If they have no support, they have no support.
> Threading and/or interrupts are
> heavily employed on those systems however, but you insist that such
> systems effectively can't be programmed because of the data integrity
> problems of preemptive instruction flows in the absence of standards
> like POSIX.
No, that's not what he's saying. He's saying that if the platform
provides no mechanism that is guaranteed to work, then there is no mechanism
that is guaranteed to work. If it does, then great, use it.
>> Aside from pure standards conformance issues, none of those distinctions
>> matter. On a Win32 system any compiler that will break threaded code
>> using
>> mutexes, or critical sections, or even events for synchronization is
>> useless junk, and nobody will use it even it doesn't technically violate
>> any formal rules.
It breaks the semantics of the mutex operations. Such a compiler, simply
put, could not compile WIN32 code. (Because the semantics of those
operations are part of the WIN32 API .)
> How can one deduce that a compiler does "technically ok" but screws up
> real-world applications? How can you guarantee correctness for the
> next compiler version that you use on a seemingly-proven-correct code?
Easy. You simply limit your coding to that which is guaranteed to work
by the compiler vendor. Microsoft does guarantee the semantics of the mutex
operations. It's not as nice and explicit as the POSIX guarantees.
> While I know your answers in advance (namely that all that is bad
> engineering and such code was broken right from the beginning) I think
> that this is a topic too important to be neglected - you are
> surrounded by systems which try on MT and are programmed in pure C.
Do you think it's useful to work out platform-independent ways to write
code that happens to work? Or do you think it's more useful to work out
precise standards that guarantee that particular sequences of code will in
fact work?
There does not exist any platform, compiler, operating system, or other
combination wherein multi-threaded code not guaranteed to work without
'volatile' is guaranteed to work with it. This makes 'volatile' de facto
useless for multi-threaded programming.
There may have once been a day when it was not possible to write
multi-threaded code that is guaranteed to work. But that is now possible and
I think it's foolish to settle for anything less. When you do settle for
less, your only choice is to use whatever happens to work. That might happen
to be 'volatile' on some platform where 'volatile' just happens to cause the
compiler to produce thread-safe code. But this is *not* the ANSI 'volatile'
keyword, it's another modifier with the same name.
DS
Mark Piffer
<David.B...@hp.com> wrote:
>I'm really not sure whether I should even try to reply, because it seems to
>me that you're working really hard to miss the point.
I'm sorry Mr. Butenhof but it seems you took my provocative questions
for a sign of disbelief. They aren't. I know that volatile and globals
etc. won't do the trick. What I (missed to) point out is that often
you find yourself programming some bare-metal system with an
optimizing compiler but you simply don't have the expertise or the
time to assert correct function of your code. Don't think the compiler
vendor will have anything but "volatile!" to say about that topic. I
have here an example of a 4000$ compiler which goes into great lengths
explaining how volatile variables are or are not influenced by certain
optimization techniques but you won't be able to make reliable
conclusions about its' ability to MT because all you read are informal
"does not"s and "will not"s. As I find myself nearer to safety
critical systems with every new job I no longer ignore the issue - but
the question remains: given compiler XY without certifications for
MT-abilities, how can you create a subset of verifiable MT-functions
where most of the proof relies on the ISO-conformance of the compiler?
Your nulla-salus-ex-ecclesiam-POSIXIAM attitude may be enough for your
job but I recommend that from now on you avoid elevators, cars and
what else heavily-MTing systems without POSIX exist out there.
>"ANSI C" (or ISO/IEC C if you prefer) and C++ don't support threads. Period.
>On any system that DOES support threads, any compiler that doesn't is
>broken. If you're using a compiler that CLAIMS to support that system,
>whether it's proprietary Win32 or standard POSIX, and they later "make a
>change" that breaks LEGAL threaded code on that platform, it's a compiler
>bug.
Ever thought about systems that don't bring any defined notion of MT
with them and which are far,far away from anything like POSIX or
Win32?
>An "ISO/IEC C" conforming compiler is useless on any
>threaded system if it performs optimizations that break threaded code.
I know and I believe you, but: take any number of electronic
components that surround you in daily life and check if they are
programmed in C and if it was a POSIX or just a ISO compiler - as I
said, stay away from any sufficiently automated machinery.
Mark
--
Mark Piffer
MCU and DSP programming & software design
Mark Piffer
<dav...@webmaster.com> wrote:
>> How can one deduce that a compiler does "technically ok" but screws up
>> real-world applications? How can you guarantee correctness for the
>> next compiler version that you use on a seemingly-proven-correct code?
>
> Easy. You simply limit your coding to that which is guaranteed to work
>by the compiler vendor. Microsoft does guarantee the semantics of the mutex
>operations. It's not as nice and explicit as the POSIX guarantees.
I fear that after naming 5 or 6 of the big names in compiler industry
you are done with those who even mention multithreading and
concurrency in their documents.
> Do you think it's useful to work out platform-independent ways to write
>code that happens to work? Or do you think it's more useful to work out
>precise standards that guarantee that particular sequences of code will in
>fact work?
But isn't POSIX a try in the platform-independence direction? For me,
one goes with the other. I have yet to see an embedded compiler which
is making any kind of affirmations in that direction, so finding out
sequences that work is in fact a bona-fide attempt because you have no
formal ground to put your assumptions on. I think that is also the
main reason for the volatile dilemma: without a formal language to
describe it's working the C standard is fuzzy enough to be mistaken.
> There may have once been a day when it was not possible to write
>multi-threaded code that is guaranteed to work. But that is now possible and
>I think it's foolish to settle for anything less. When you do settle for
>less, your only choice is to use whatever happens to work. That might happen
>to be 'volatile' on some platform where 'volatile' just happens to cause the
>compiler to produce thread-safe code. But this is *not* the ANSI 'volatile'
>keyword, it's another modifier with the same name.
Dave you don't need to convince me about the inadequacy of volatile
but I can assure you that the real action is happening elsewhere. The
millions of lines of C that are daily written for small systems (much
too small to show up on the POSIX-radar) and which happen to end up in
all kinds of automated mechanisms surrounding us. Volatile is not mine
or the problem of a stubborn Mr.Newcomer. It's all ours. Give compiler
optimizers 5 more years and let modern (cached, pipelined, whatever)
CPUs invade the field of classical 8 and 16-bit micro applications and
you will have a real MT-chaos in the field.
> DS
Thanks for your constructive answer, Dave.
Doug Harrison
>I have here an example of a 4000$ compiler which goes into great lengths
>explaining how volatile variables are or are not influenced by certain
>optimization techniques but you won't be able to make reliable
>conclusions about its' ability to MT because all you read are informal
>"does not"s and "will not"s. As I find myself nearer to safety
>critical systems with every new job I no longer ignore the issue - but
>the question remains: given compiler XY without certifications for
>MT-abilities, how can you create a subset of verifiable MT-functions
>where most of the proof relies on the ISO-conformance of the compiler?
I think it's as simple as this. If the compiler is intended for
multithreaded programming, it will honor the expected semantics of the
synchronization operations. If it is not so intended, then you should
look elsewhere for your MT programming needs. If it is so intended,
and it does not explicitly require volatile on top of synchronization,
yet there are places where you must use volatile on top of
synchronization, I'd call those places "bugs". If it does explicitly
require volatile on top of synchronization, then I'd look for another
compiler, written by people who understand MT programming.
There are many reasons why it would be ridiculous for a C++ compiler
to require volatile on top of synchronization. I described some of
those reasons in these messages in comp.lang.c++.moderated:
http://groups.google.com/groups?selm=9i4g50tov6hefrpdsaui1mrvgpskc9m1gu%404ax.com
http://groups.google.com/groups?selm=4hc46094248f3t1kja3kcijqq4221hsc5k%404ax.com
--
Doug Harrison
d...@mvps.org
David Schwartz
"Mark Piffer" <mark....@chello.at> wrote in message
news:4065782a...@news.chello.at...
> On Tue, 23 Mar 2004 19:13:54 -0800, "David Schwartz"
> <dav...@webmaster.com> wrote:
I don't think we disagree about anything, I think we just are each
putting a different spin on a different set of facts.
All I'm trying to say is that you have two choices, you either follow a
standard (or whatever is close to a standard that you have) to produce code
that's guaranteed to work, or you use whatever happens to work on your
platform. There is no platform, standard, or quasi-standard that I know of
where 'volatile' is guaranteed to work. If 'volatile' happens to work on
your platform, it's not because of the ANSI semantics (since they don't say
it will work).
>> Do you think it's useful to work out platform-independent ways to
>> write
>>code that happens to work? Or do you think it's more useful to work out
>>precise standards that guarantee that particular sequences of code will in
>>fact work?
> But isn't POSIX a try in the platform-independence direction?
POSIX isn't a "try", it's a set of guarantees. If your compiler,
libraries, and platform claim POSIX support, then in theory you are
*guaranteed* that your code will work on every such conforming platform.
>> There may have once been a day when it was not possible to write
>>multi-threaded code that is guaranteed to work. But that is now possible
>>and
>>I think it's foolish to settle for anything less. When you do settle for
>>less, your only choice is to use whatever happens to work. That might
>>happen
>>to be 'volatile' on some platform where 'volatile' just happens to cause
>>the
>>compiler to produce thread-safe code. But this is *not* the ANSI
>>'volatile'
>>keyword, it's another modifier with the same name.
> Dave you don't need to convince me about the inadequacy of volatile
> but I can assure you that the real action is happening elsewhere. The
> millions of lines of C that are daily written for small systems (much
> too small to show up on the POSIX-radar) and which happen to end up in
> all kinds of automated mechanisms surrounding us.
This falls into the "do whatever happens to work on your platform, but
you have no guarantees" category. In this case, "volatile" is neither
required nor sufficient. If it's required, who or what requires it?! If it's
sufficient, who or what assures its sufficiency?
> Volatile is not mine
> or the problem of a stubborn Mr.Newcomer. It's all ours. Give compiler
> optimizers 5 more years and let modern (cached, pipelined, whatever)
> CPUs invade the field of classical 8 and 16-bit micro applications and
> you will have a real MT-chaos in the field.
I think you'll find more and more smaller compilers and platforms
supporting at least portions of the pthreads standard. At the minimum, its
memory visibility rules. (Probably along with lighter add ons such as atomic
integer operations.)
DS