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:
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.
Not sure. Incidentally, there s a strong parallel between the type of
work I do and parts of ACE. I will take a look.
[snippage]
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).
I had more experience with Windows than Unix for a long time until
length of time with Windows overtook length of time with Unix. I never
thought I would say it, but the thought of not having bona-fide threads
is frightening. I wonder if there will ever be convergence on things
like this (file system being another example). Or asked another way,
"Are there fundamental themes that are universal, like the notion of a
stack?"
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?
Design possibilities and structural sensibility. I forget the
thought-process I went through while making my thread frame work, but I
did go deep into the rat hole. When I came out, I concluded that you
should use explicit new() and delete() to make thread "objects". Mirek
Fidler apparently has an alternative model that uses full-blown RAII.
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?
It seemed so. Of course, I did not just make a thread class. I tried
to think about it from a systemic point of view. For example, thread
cancellation with orderly shutdown of that thread is desirable. I
might be nice to wait for a thread to die. It might be nice to wait
for an event, three mutexes, a semaphore, and 2 threads to die, or any
one of these things to be signaled, etc. I was able to make all
classes RAII, Yin/Yang style (mutexes, etc) except the thread class.
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?
Or even Windows. I went for a long while just using
WaitForSingleObject, with an occasional timeout. But there are moments
when you are designing a system that, even thought it works, it simply
does not feel quite right. In this case, I heard myself saying, "Ok,
this works, but it's ugly. Too bad there is no way to wait for many
things at same time...that is..." Then I remembered
WaitForMultipleObjects. I wrapped it and integrated it into the
framework. I used my Event, Mutex, Semaphore, List<> and Set<> classes
to work with it..and in one afternoon, got rid of all the timeout
values that I had been using for WaitForMultipleObjects. One function
shrunk in size from 800 lines to 300. And the code made sense. Of
course, Microsoft's limitation of handles let you only wait for 32, but
so far, I wait on maybe 7 or 8 objects at once. And it is all in C++.
As you can guess, I am really excited about this. Finally, blocking
can really be blocking, indefinitely, instead of say, for 8 hours then
checking to see if you are hung.
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.
Why have more threads than the number of processor cores?
The threads are not simply replicas of thread T, they are T, U, V, W,
and Z, all different. At any given time most, if not all, are in
wait-state, consuming essentially no quanta.
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]