Re: Threads - When?
Le Chaud Lapin wrote:
Lourens Veen wrote:
int i(42);
struct A {
A() : a(new int) {}
~A() {
delete a;
}
A(const A &);
int * a;
};
int f() {
A a;
++i;
}
int main() {
f();
std::cout << i << std::endl;
}
Would an optimising compiler be allowed to move the increment of i in
f() to before the construction of a if that is more efficient? Well,
yes, since there is no interaction between the two, so the result
would be the same.
I would expect the value that is printed out to be 43.
And that's almost all that the standard requires. (The presence
of new and delete complicate things, since the user can replace
them, and the replacement could cause different observable
behavior depending on the value of i. But a compiler could very
easily determine whether the replacement functions access i or
not.)
A good compiler might even replace the entire program with the
equivalent of:
int
main()
{
std::cout << "43\n" ;
std::cout.flush() ;
}
And be done with it. (And some compilers are this good.)
I do not agree that the compiler writer would be allowed to reorder the
statements so that i is incremented first. For example, there is only
the declaration of the copy constructor of A above. There is no
guarantee that the definition of the copy constructor does not depend
upon the value of i.
The code never calls the copy constructor, so what it does is
irrelevant. If it did call the copy constructor, there must be
a definition of it somewhere, so the compiler can know whether
it affects the value of i or not.
So in a world were there were no such thing as
multi-threading, IMHO, a reordering of the code would be incorrect.
You don't seem to understand how good optimization works. The
best optimizers today look at the entire program. (I think that
even VC++ does this now.) The C++ standard defines the
semantics of the entire program, not just individual functions;
given program x, and input y, the observable behavior is z. The
compiler can do anything it wishes, as long as the observable
behavior is z. In fact, there can be several different
legal observable behaviors, and all the compiler has to do is
ensure that the actual observable behavior corresponds to one of
them. And the compiler has the right to assume that the program
contains no undefined behavior.
[...]
Finally, the really, really big one, the one that ties everything
together, and makes you feel like you do not have to struggle with
managing what would otherwise be overwhelming complexity, is none other
than WaitForMultipleObjects and its equivalents. This surprisingly
useful function that I had originally placed in the
"Hmmm..interesting...not sure why someone would want that...." category
long ago when I first saw it.
Curious. I felt it intuitively natural, and implemented it in
my very first OS (back in 1980). On the other hand, it's fairly
easy to simulate: just wait for each event in a separate thread,
and have them feed into a common message queue.
It's actually not unusual for all external events to feed into a
single dispatcher thread, which in turn ventilates them out to
the different processing threads.
The day I discovered what it is really
used for, I was ready to kiss the feet of the Microsoft engineer who
wrote it. This function is crucial for large, complex, multi-threaded
applications!
I'd say that it's far more useful in small applications, things
simple enough not to need central dispatching. But of course,
you implement it once, and then reuse the implementation.
(There are also tricks under Posix using pipes: for every event
in the queue, you write a single byte in a pipe; you can then
wait on multiple pipes using select.)
Again, I do not use these primitives in the raw. I have a set of
wrapper classes, which makes using the more pleasurable than the raw
Microsoft API.
Basic primitives that you might need to write large multi-threaded
applications:
1. Events
2. Mutexes
3. Semaphores
4. Waitable Timers (block until a point in time occurs. *not* the same
as sleeping)
5. Critical Sections (spin in user mode, drop to kernel if spin did not
work)
That's a mutex, not a critical section. A critical section
protects a block of code, not data, and as far as I know, is not
actually implemented in the more modern OS's. (It's not present
in either Windows or Unix, for example.)
5. WaitForSingleObject
6. WaitForMultipleObjects (importance should not be underestimated,
IMO)
You definitly want conditions, or something along those lines.
Things like spin-locks, asynchronous procedure calls, condition
variables, timer queues, atomic operations, fibers...these can be
useful in other circumstances...but I would think that a C++ programmer
who wants to have something relatively complete without too much fuss
could get by with these, all wrapped of course.
It depends on the application domain. In my own work, all I
need is message queues and mutexes; message queues are
implemented in terms of conditions. For people doing numeric
work, however, where the purpose of multi-threading is to spread
the work out over a large number of CPU's, these are too heavy
weight, and something simpler and lighter is called for.
The problem with defining the user interface is precisely that
threading serves many different purposes, in different
communities.
--
James Kanze (Gabi Software) email: james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, 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! ]