Re: Threads - When?
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.
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. So in a world were there were no such thing as
multi-threading, IMHO, a reordering of the code would be incorrect.
Now imagine A is a lock class rather than a useless one, and that
there's another thread calling f(). And then explain to me how the
library people and the OS people are supposed to prevent this from
happening.
I do not understand what you mean by a lock class. Do you mean it
acquires a lock?
If there is a potential for deadlock because some function is calling
another function that contains an auto object that will block on an
attempt to call a lock, that is the fault of the programmer, not the
language. The perennial question is, as always, :
"What was the programmer trying to do when he did that?"
Threading is an OS issue, not a language issue. It is OK to have
expectations of what the OS supports. I do not think it is ok that
the "power of the language" will make all better. In other words, I
would be entirely happy if the OS people provided a full set of
primitives, and the C++ built a portable library on top of those
primitives.
But how do you define what the primitives in this library do?
Ah. This is a catch-22. It is difficult to develop an intuitive
notion of what primitives are necessary without gaining much experience
with multi-threading. But it is difficult to gain much experience with
multi-threading if ones spends too much time trying to debug race
conditions and deadlocks.
There are two solutions to this dilemma:
1. Study first then do. I imagine that a programmer's experience with
synchronization often comes when there is a need to implement
multi-threading in an application. This might not be the best approach
to learning. Perhaps it would be better to experiment first, not on a
production system, but a toy. Play much. Get a good feel for what
everything is for. Do not make the same mistake I did and assume that
much of what you see is superfluous, for example, in the case of
Microsoft's implementation. The day might come where you change your
mind. After playing and learn, _then_ apply to real systems, but do not
use the API in the raw. It is too unsightly for that. Use C++ wrapper
classes to wrap. DuplicateHanndle and its equivalent are necessary.
2. Talk to experts, the kind that spend 6 hours a day in the kernel.
It seems that the C++ community is not yet aware of the right question
to ask about threading. If this is the case, it takes only a simple
conversation with, say, 10 experts, who have been working with
synchronization for 30 years, and at least convey to them the visions
we have, no matter how vague they are. Those experts will be able to
complete the picture, and indicate if we are asking for something that
we think we need but do not. If the opposite is the case, then they
will indicate that also.
If #1 is the approach, after learning, write multi-threaded
applications. Write many. Get burned once or twice (a burn can last
several days if it is really hot). There will come a point when the
same primitives recur repeatedly. Not suprisingly, they are the ones
you would expect from reading any book on OS design: Events,
Semaphores, Mutexes. Then, if you do any real-time or device driver
work, you can see where spin-locks make sense. Then you might do some
timer-related work, such as processing any of N queues that are
schedule for processing at different times. Waitable timers shine
here. Then you can see that system-wide mutexes are inefficient if you
are using them in the same process (related group of threads on
Windows), so the addition of user-mode spin-locks with mutex failover
becomes a very-nice-to-have, and come to appreciate what Microsoft
chose to call critical sections.
There are other primitives both in user-mode and kernel-mode for atomic
test-and-set, pointer swapping, etc. Bus-locking has been around
forever. These are useful of course, but the ones that the average C++
programmer needs to write (very large) multi-threaded system are the
bread-and-butter primitives: events, semaphores, mutexes, waitable
timers, critical sections.
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. 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!
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)
5. WaitForSingleObject
6. WaitForMultipleObjects (importance should not be underestimated,
IMO)
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.
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]