Re: To thread or not to thread ?
JohnQ wrote:
The threads of discussion about threads have been enlightening in exposing
some of the low level issues which could possibly affect MT code and,
more importantly, served also to bring awareness to the unsuspecting (me
for one). It leaves me wondering if writing MT code is even to be pursued
at this point in time, or at least "where's the guidebook to read is that
will
facilitate the writing of MT code without engaging compiler-level
gotchas?". Can the low level issues be dealt with in the short term by
following certain rules, perhaps platform-specific ones, or is robust MT
code not a possibility at all at this time? Are the low level issues just
ones
of portability and therefor all those MT Windows programs developed
over the last few years, for example, can be considered probably OK in
regards to those compiler-level issues?
IMO, you can write robust multi-threading applications today that work
on the major operating systems (Windows, Unix, etc.) And yes, the
issues are primarily related to finding a common API that more or less
remains constant and making sure that the OS designer has provided a
sufficient set of kernel-mode primitives.
With my own projects, I decided to familiarize myself with the
synchronization primitives on one platform (Windows), knowing that, if
the engineers "thought it through" enough, then most likely, there will
be parallel primitives on the other platforms. Many of the people who
did the Windows kernel-mode work came from VMS (I heard), which
probably explains why I have been so pleasantly surprised that they did
"think it through" in times of doubt. (PulseEvent notwithstanding).
IBM wrote a series of articles for porting multi-threaded applications
that will help get a broad overview of who is doing what. Things like
named kernel-mode primitives can be highly useful, and have been with
Windows for a long time, but not so long on Linux. What would help is
help is to have a comprehensive set of kernel-mode primitives across
all OSes, but of course, this can force the question of what is
fundamental and what is not, for example, with whether there should be
real, bona-fide, intra-process threads. [Yes on Windows, Not Always on
Unix].
http://www-128.ibm.com/developerworks/library/l-ipc2lin2.html
I wrote a C++ wrapper framework that encapsulates the OS primitives on
Windows. Naturally, this implies that one has thought about usage
patterns of synchronization in multi-threaded applications, which,
while not too difficult for the easier primitives like events, mutexes,
and semaphores,...becomes a bit harder when you try to make a "thread
class". Many programmers have tried to make "thread classes" only to
find that there is a severe penalty for choosing a wrong conceptual
model. I fell into this trap. The best advice I can give in this
regard is to say that the concept of the thread itself should not be
modeled as a class.
The other best advice I can give, by far, is not to underestimate
WaitForMultipleObjects on Windows and its equivalents on other OSes.
It provides significant mental relief while design systems where many
different things are happening at once and all need to be waited on by
multiple threads, and yet still, you want to have the confidence that
the design is will scale no matter how many global objects you have an
no matter how many threads you have running (within reason). For
example, 25 global objects with, say, 20 distinct threads, each thread
operating on 3 or 4 of the global objects, would be easy conceptually
with WaitForMultipleObjects, but could quickly turn into a quagmire if
trying to accomplish the same thing with WaitForSingleObject and
time-outs.
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]