Re: C++ Threads, what's the status quo?
Le Chaud Lapin wrote:
James Kanze wrote:
Le Chaud Lapin wrote:
The point is that C++ and threading are alive and well. People use
them together. Some people use the native API of their OS, which is
not always pleasant to use. Some people wrap these API's.
The point is that you don't know that it works, and that it
works only by chance (and may actually fail once you start using
a multi-core processor). The point is that you don't have any
guarantees with regards to what the language or the compiler
provides.
I never asked the compiler for any guarantees. What did you study in
university? I do not mean to attack you personally, but frankly, these
concepts are as old as multi-threading itself. I am appalled that so
many people seem not to understand multi-threading.
What does my university training (or lack thereof---I never
studied at a university) have to do with it. I do know
something about multi-threading, and what I don't know, I know
people who I can ask. And I've something more than thirty years
experience, including having written an real time operating
system and a compiler, and having developed threading concepts
in several different projects. I've worked on multi-processor
systems as well, and know some of the issues involved there as
well.
What appalls me is that you don't read the postings you answer.
Rather than attacking people as incompetent, you should read
what they are saying. You critize arguments that were never
made, and proposals which no one in their right mind would
suggest, but you don't comment on the real problems being
exposed.
I've written compilers, and I know that the option exists to use
static memory. I've used compilers (g++ pre-3.0) which actually
did so. Unless the compiler gives you some explicit guarantee,
you don't know when it will do so, and you cannot use that
compiler in multi-threaded code. That's all there is to it. If
you don't know when it might use static data, you have no means
of knowing what you need to protect.
I also know how optimizers work, in particular, the importance
of moving loads forward. Even accross function boundaries, if
the function doesn't modify the variable being loaded. (Note
that if you read the Sparc specifications, you'll see that even
the hardware can do this, independantly of the compiler.)
Maybe your happen with a definition of "working" as "it hasn't
crashed yet", but my customers generally aren't.
One of my multi-threaded application has 11 threads in it at minimum,
rising to 35 if necessary. This application will never crash "because
of threading."
Will never crash, or has never crashed? Will never crash means
that you've proved it correct, and to do that, you need some
guarantees from the compiler (and the standard library). How do
you know that when you write y = a * x + b, the compiler doesn't
store the intermediate result a*x in static memory, even if all
of the variables are local?
But I do not think it is fair to say that we do not understand the
importance of multi-threading programming by C++ programmers. We do.
What we are saying is that the fundamentals of multi-threading,
barring
some massive break through in the state-of-the -art, are
well-understood,
Which explains why so many programmers get it wrong. (The
people who implemented std::basic_string in g++ are not idiots;
they're some of the more gifted programmers I know. Never the
less, there is a threading error in the code.)
There is no "threading" error in the code. If I write
int x == 10;
(I'll suppose you mean "int x = 10".)
int thread1 ();
int thread2 ();
...and let those two threads fiddle with x without the protection of
mutual-exclusion, there will be contention. Are you saying that the
people who designed std:basic_string designed it expecting there would
be no contention?
I'm not sure what your point is. std::basic_string almost
certainly uses some static variables, if only to allocate
memory. The standard doesn't forbid it, and in fact, you can't
implement a memory allocator without it. The implementations I
currently use are guaranteed thread safe (or almost), and the
implementations of the allocators use locks or other
synchronization primitives to provide thread safety. And
explicitly document this fact. In the case of malloc, it's
required by Posix. But std::basic_string isn't required to use
malloc directly, and some implementations, including g++ and
Rogue Wave, use COW, which can also cause threading problems.
That's a fact of life. Whether you like it or not.
and it is our opinion that those who think that the language
itself is somehow deficient in this regard are mistaken.
You can think what you like, but you can't argue with hard
facts. It is impossible, today, to write a multi-threaded
program with defined behavior.
I do it every day. I know how to write multi-threaded applications.
Apparently not. At least, you refuse to answer the problems
which are presented to you.
There are probably 10,000's of programmers who do. One should not
assume that others are unable to do that which he cannot.
I doubt that there are currently 10,000's of programmers who
write correct multi-threaded code. It can be extremely
difficult, and even the experts make mistakes at times: I found
an error in the implementation of basic_string in g++, and
several in ACE.
For the moment, I think the committee has only begun to scratch
the surface with regards to primitives. Before defining the
primitives, it is necessary to define a basic memory model; what
it means to read or wite to memory.
I am going to give the committee the benefit of the doubt and assume
that at least some of them understand the basics of synchronization and
OS design.
That's nice of you. Given that the person currently doing the
most work on the threading issues is also one of the world's
experts on threading issues.
But the more I read this thread (no pun intended), the more
I get the feeling is that real problem is simply that there
C++-is-lacking-thread support crowd is primarily composed of people who
have very little or no experience with multi-threading.
I think the problem is that you aren't reading it. Because the
responses I've seen have consistently shown more threading
expertise than you have shown.
I wish someone who writes operating system books for a living were
reading this. I cannot stop laughing as I am reading this post. The
examples presented so far, two threads modifying a global
variable....leaves me...speechless.
Again, I can't find what your point is. It's well known that
two threads cannot modify shared data without synchronization.
The point that I've been making is that without compiler
support, you, the programmer, cannot provide that
synchronization because you don't know when shared data is being
modified.
In all fairness, I know that there are probably a few lurking
16-year-olds who, though bright, having gotten around to mutual
exclusion, and are so not sure who has more insight, so I offer this
link to get you started so you can plainly see that this is a very old
concept:
http://en.wikipedia.org/wiki/Mutual_exclusion
I did not study computer science, but if you are reading this, and you
studied computer science, and you do not understand the basics of
mutual exclusion, or equivalently,
if you are in anyway, even _one iota_, surprised that a global static
variable used by std::string cannot be accessed read/write by multiple
threads without a mutex, I am sorry, there is simply no excuse - you
should be ashamed of yourself! ?????? What do you expect??!!
Again, it would help if you'd read the posts you are replying
to. Where did anyone (but you) says anything so silly. What
everyone else in this thread is saying is that without explicit
guarantees, you don't know who uses shared variables, where.
That without explicit guarantees, the compiler can generate code
which uses them. That without explicit guarantees, the compiler
can move your code across synchronization primitives, so that it
is no longer protected.
See the following link: http://bardavid.com/mead/
The link doesn't seem to be working for me at the moment.
"The mutual exclusion problem was formally defined by Edsger Dijkstra
in 1965."
Actually, it goes back to before that. Dijkstra formalized
certain aspects; Hoare as well.
These concepts are more than 40 years old, and multi-threaded
applications are written all the time, not just in C/C++, but in *many*
languages.
I am so perplexed by this discussion, I am going to over to the threads
group to see what they have to say.
Doubtlessly what I've been saying, since I'm mostly quoting
things I learned from discussions there.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientie objet/
Beratung in objektorientierter Datenverarbeitung
9 place Simard, 78210 St.-Cyr-l'Icole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]