Re: To thread or not to thread ?
Le Chaud Lapin wrote:
JohnQ wrote:
[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).
There is already some convergence: Vista has adopted parts of
the Posix model. And Posix is vague enough to allow several
different underlying implementations; at least one of the Linux
threading implementations isn't that far from the Windows way of
doing things (although the Posix level interface doesn't always
make it that obvious).
Or asked another way,
"Are there fundamental themes that are universal, like the notion of a
stack?"
There are several fundamental themes. The problem is that some
of them are mutually exclusive, and until recently, threads
weren't widely enough used to be able to judge from experience
what was best.
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.
Traditional models tied thread lifetime to a "thread" object.
This creates some fairly complex lifetime of object issues for
detached threads.
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.
But it is so simple to emulate. Just start a thread for each
thing you want to wait for, which posts a message in a queue
when that event arrives, and wait on the queue in the main
thread. (But I agree that it is nice for the system to do it
for you.)
--
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! ]