Re: Threads - When?
James Kanze wrote:
Le Chaud Lapin wrote:
I think that it is possible to use C++ as it is effectively in a
multi-threaded environment, provided that good primitives to support
such an environment have been created. In particular, the
synchronization primitives are critical (no pun intended).
You need more than primitives. As long as accessing memory from
two different threads is undefined behavior, you cannot write
multithreaded programs. And the current sequence point model
simply doesn't work in a multithreaded environment.
It's not undefined in my framework. I use old-fashioned
locking/unlocking.
C++ has a requirement that it be implementable under current
operating systems. Under current operating systems---at least
under Solaris and Linux, and I think under Windows---there is no
way to implement a general solution to these problems; both
require significant collaboration in the manipulated thread. So
it would be extremely surprising if the C++ standard required a
solution to them. And useless---a standard that cannot be
implemented under Windows or Unix isn't of any interest to
anyone.
I have Windows and Linux covered meaning that, if you use only the
interfaces of my synchronization primitives (Mutex, Event, etc.) it
will cross compile, but the implementation is not portable of course.
But if you compile the _code_ that uses these primitives, that code is
portable in the strictest sense, meaning, it is not possible to look at
the code and tell which OS is for. This hints that there are actually
two problems:
1. Having available the basic primitives of synchronization
2. Constructing a framework in such way that the use of that framework
does not drive the programmer insane.
These are two separate issues.
The first problem is the domain of the OS people. For example, if
there were no atomic operations like test-and-set, or even an
ALU-managed XOR to external store, there would be nothing the C++
library writer could do to guarantee safeness. Luckily, that's not the
case. We not only have that, we have a lot more. It's just that some
OS vendors have not paid attention to those who have already crossed
the finish line.
Once the first part is done, then the second part can be finished, but
not before.
This is what I said about the OS people doing their part. If such a
framework is to have and minimal standards of elegance, it has to be
pure C++ to start with, the model itself has to make some sense, the
usage pattern has to make some sense, and there cannot be any
unexpected quirkiness because you had to compensate for the lack of a
kernel-mode primitive on a particular OS (like spawning a new thread
just to get a WaitableTimer on Windows CE).
In my experience, despite Win32's bland synchro API, it is wrappable,
and what is surprising is that if you ignore the limitation on number
of handles for WaitForMultipleObjects, and the fact that Windows CE
does not support Waitable Timers, all the primitives to provide closure
for synchronization are present. IBM also did a great job showing that
the same model can be realized on Linux.
The most important thing I think that is coming out of all of this
activity is that the realization that certain primitives are
fundamental, and not really optional, something discovered long ago
with Dijkstra's execution stack as it became generally accepted that an
execution stack is not something he simply dreamed up and thought would
be nice to have, but fundamental.
Also, to remain honest, I did not do critical sections, which means I
use Mutex's exclusively for locking, with performance hit, but that
will fixed. My gut feeling is that Microsoft implemented them using
nothing more than test-and-set with failover to a real mutex on
Windows. I neglected them because it was hard to make something
portable if your C++ class must include in its declaration something
that #include's from Wnidows.h].
So to summarize: The OS people can make the primitives as raw and
unsightly as they want as long as the primitives are present and
complete. From that, it becomes easy to write a clean, C++ wrapper
framework to support robust multi-threading.
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]