Re: To thread or not to thread ?
JohnQ wrote:
"Le Chaud Lapin" <jaibuduvin@gmail.com> wrote in message
news:1168399666.909953.168890@p59g2000hsd.googlegroups.com...
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.)
Well obviously anyone who's been reading the thread threads knows that
is what you think!
Of course, he hasn't actually tried to do it:-). My experience
is that you can write robust multi-threaded applications for a
specific implementation, but that they won't be portable. (And
the API is the least of your problems.)
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.
Doesn't ACE attempt to provide a wrapper across current platforms?
That sounds wrought with peril given the discussions here lately.
Probably better to be platform-specific at this juncture.
That's why there's an attempt to standardize. (FWIW: I gave up
on ACE because I found too many errors and false assumptions in
it.)
It be nice for the compiler guys at Microsoft to chime in and say that
they've thought about issues brought up here and get them to say
absolutely say yes or no as to whether there are potential dangers and
what they are.
The problem is that it is "guys", and not just "guy". As with
most big companies, you often get cases where the left hand
doesn't know what the right hand is doing. In the case of
Microsoft, there are definitly people in the technical pars of
the company who have taken all of the points mentionned so far
into consideration, both in the OS group (working on Windows),
and in the compiler group. I'm less sure that the people in
documentation are as up on the issues, so it's possible that the
guarantees aren't correctly documented.
I know that after following the thread threads I'm not going
to be turning on the optimization flags on the compiler anytime soon for
one thing.
A good policy even in single threaded code. Until you need the
performance they give.
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),
And with VMS being a realtime OS, that bodes well.
I don't think that there's any doubt as to the competence of the
people implementing Windows, nor of their awareness of the
issues. But that's no proof that the got everything right,
either.
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].
Well get the UNIX folks to pick up on the Windowisms is not going to
happen (though I personally wish it would because that's where I'm
from).
FWIW: the person who developped Boost::threads comes from a
strong Windows background. He adopted a model based on Posix
because he found it significantly superior. (That is, at least,
what I have been told. And from the Boost::threads
documentation: "Event variables are simply far too error-prone.
boost::condition variables are a much safer alternative.") It's
also significant that Vista adopts condition variables; this may
be only because they feel certain that that will be the model
adopted by the C++ standard, and not for any particular
technical reasons. And the Boost library does implement
condition variables under Windows, using Windows OS primitives,
so it must be possible.
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.
What kind of penalty? Performance or constrained design possibilities?
Probably both.
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.
That's exactly how I did it years ago. That's probably where I'd start
from again if/when I dust off and revive that code. I was probably
influenced by the Borland class library and maybe even MFC. So
you think they got it wrong huh?
There are two philosophies: a thread is an asynchronous
function, or a thread is a class. The Boost model tries for a
sort of compromize between the two: a thread is a class, but one
that acts like an implicitly called functional object, and whose
lifetime doesn't need to extend to the lifetime of the entire
thread.
In my own work, I distinguish between joinable threads and those
that you "fire and forget". Joinable threads are a class, so
you have something to join with; detached threads are started by
a simple function call.
Another philosophy involves "futures": basically, it consists of
a function to start the thread; the function returns an object
which can later be used for joins.
And of course, it's arguable whether one can even use detached
threads in a correct program. It certainly makes clean shutdown
more difficult. (On the other hand, many of my programs run
forever, so this isn't an issue.)
Anyhow, as you can see, this is an area where there is very
little, if any, consensus. (At least there is a consensus in
the committee that you must also be able to use system level
threads, i.e. that whether you start the thread using the
"standard" way, or a low level system call, all of the other
threading guarantees hold, you can still synchronize with
standard mutexes, etc.)
The other best advice I can give, by far, is not to underestimate
WaitForMultipleObjects on Windows and its equivalents on other OSes.
Why would anyone "underestimate" that? My guess is you're talking
about those who have a UNIX/POSIX background right?
I suspect that most of the people who "underestimate" it simply
know how easy it is to provide, given the basic threading
primitives. There seems to be a consensus amongst the threading
experts that only two primitive objects, mutexes and condition
variables, are necessary. Everything else can be implemented in
terms of them. (Of course, it's nice to have it already done
for you, and I was quite happy to use rwlocks when I needed
them, without having to implement them myself using mutexes and
condition variables; even if I know how, it's more code to
write and to maintain.)
Glancing through the Windows documentation, my impression is
that in addition to condition variables, it is missing some way
of statically initializing mutexes. This would seem essential
to me in order to maintain encapsulation (and well over half of
my pthread_mutex_t are statically initialized). This would be
less of a problem if the compiler allows unsynchronized use of
local static variables with dynamic initialization, but since
one of my target compilers (Sun CC) doesn't, I can't take
advantage of it.
Ideally, you also want some means of signaling a thread that you
want it to shutdown, along the lines of pthread_cancel. I
haven't seen an equivalent in Windows, and of course, the
semantics of pthread_cancel are not defined in C++ (and
different compilers define them differently), which doesn't help
either. (I might add that there has been enough discussion in
the C++ committee to make me think that there isn't really any
consensus as to what the semantics should be.) In the meantime,
you have to improvise, using some sort of global flag, and
ensuring that no thread does an indefinitly blocking call.
(This typically means that you can't use std::cin.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientie objet/
Beratung in objektorientierter Datenverarbeitung
9 place Simard, 78210 St.-Cyr-l'Icole, 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! ]