Re: To thread or not to thread ?
JQP wrote:
Le Chaud Lapin wrote:
I never
thought I would say it, but the thought of not having bona-fide threads
is frightening.
And by that you mean on any other platform or that either Windows or
UNIX is lacking them? By "bona-fide" threads, do you mean real threads
rather than something like pthreads?
Yes and yes. My system model will fall apart on an OS that does not
have threads. For example, I remember trying to choose between Windows
CE and PalmOs for a "small device" test system. When I saw that Palm
OS did not have multi-tasking, the answer was easy. They do have
Cobalt now, but to not have had it before says something about the OS.
Also, for a while, creating threads in Unix was not as simple as doing
a CreateThread. The newer models like LWP seem to have helped a lot.
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.
explicit new() and delete() as opposed to.... what? As opposed to being
wrapped up in one of your "Yin/Yang" classes? Please give a tiny
example of what you mean by "Yin/Yang" class. I tend to think of
yin/yang as sort of an equal and opposite reaction, or better,
completion of something. Complementary: not the same and not the
opposite, but complementary. So are you just wrapping new and delete of
an object in a constructor and destructor of a wrapper class?
Yin/Yang in the context of my thread class is equivalent to RAII.
CreateThread is in the constructor, and CloseHandle is in the
destructor (effectively). Normally, I make most of my objects
copyable, but decided that it was not appropriate to make thread object
copyable. My containers assume copyability, so I had to use pointers
to objects in the container: new()ed.
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.
Well that could be put into a thread class (orderly shutdown). Indeed
that would be a reason to wrap the platform abstraction. But yes, other
threading things like locks are the obvious ones to wrap up (one of
mine is called AutoLock which wraps a mutex).
Yep. My thread class includes as part of its design a mechanism for
orderly shutdown. I would not be surprised if the code is the same.
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.
And the reason you couldn't make an RAII-style thread class is....?
Honestly, I cannot remember. I has been a while since I worked on the
synchronization part of my library. I do remember that making the
thread class copyable was not good. Cannot remember why. My brain
cycles have been usurped by crypto over last few weeks.
Well I'm happy for you that you found the WaitForMultipleObjects
function. Are you enamouring about it here because you think most
people here are UNIX developers? Am I missing something about how you
are using WaitForMultipleObjects that is remarkably different than what
it was designed to do?
No, not really. I am not adding anything new in terms of functionality.
There were many places in my code where I needed to wait for multiple
things, but could not block indefinitely, so I would have to wait "a
long time", but "not too long", using time-outs on WaitForSingleObject.
Those time-outs are all gone now, and I really can "block
indefinitely" waiting for 5 or 6 things of various kinds (events,
mutexes), etc. to happen at one. The framework is not necessarily
bound to the Windows model, so it looks like portable C++.
I see. I was asking a bit facetiously to bring up the points about when
1 thread per core is warranted over more than that.
Should be interesting one day to share system designs. ;)
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]