Re: Threads - When?
Gerhard Menzl wrote:
Le Chaud Lapin wrote:
Gerhard Menzl wrote:
struct A { A(); };
void f()
{
static A a;
}
I was hoping for this example.
Then I wonder why you didn't bring it up yourself. *g*
My position:
Given that there is really only one variable for multiple threads, and
that, if the function is expected to operate against that global
variable, then multiple initializations is only one problem - there
remains the problem of mutual exclusion.
Redesign the code, make the variable global (just outside the
function, if necessary), and put a mutex on it.
Why should I be forced to make a variable global when its scope is local
by nature?
Because it is actually global in nature.
I am sorry, but to me this is just a cop-out. I think that
this sort of well-don't-do-that attitude is not enough to make C++ stay
competitive.
Then be prepared to change many things about C++. If a function F(x)
returned the digits of Pi on each call, but also happened to launch a
ballistic missile on each invocation, you could not blame the compiler
for the side effect of superfluous launchings caused by multiple use of
the function name in an expression. There are many things in C++ that
presume that the programmer has context about they way things are.
This is simply one of them, IMO.
There has been wide agreement in another thread here
recently (I don't remember which) that there are far too many cases of
undefined behaviour in the language. This, like multithreading in
general, is one of them, so it should be addressed by the standard.
Well, as I have said before, when I look at that code, I never had any
illusions that it was not a global variable. The only thing I was
curious about was whether the compiler would initialize the global
variable before call to main() or wait until the first invocation of
the function. So I checked my TCPPPL, and saw that it was on first
invocation, which immediately lead to the question, "How does it know
it's the first time", which mean a global variable, which immediately
leads one to think, "Ok, I guess that works, but in a multi-threaded
program, it is going to be an issue."
But not one that is easily circumvented.
Note that this does not mean that synchronization primitives go into the
core language, as in Java. It simply means that the definition of the
abstract machine acknowledges concurrent paths of execution. None of
your points about treating multiple threads as a high-level design issue
is invalidated by this.
Yes you're right. I definitely support discussing multi-threading
discussions in context of C++. Perhaps I was wrong to assume that
there are people who feel like the solution is to augment C++ with a
bunch of synchronization-related keywords, or worse, magically
ascertain the intent of the programmer in a complex, multi-threaded
application.
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]