Re: Critique ThreadQueue class please
- From: "Jim Langston" <tazmaster@xxxxxxxxxxxxxx>
- Date: Fri, 17 Feb 2006 14:05:14 -0800
"Joe Seigh" <jseigh_01@xxxxxxxxxx> wrote in message
Jim Langston wrote:
I've modified a class I found on the net for thread communications and am[...]
looking for critiques. Anything at all that you would do different or
that may not be what I wanted. I've tested it for 1000 threads and it
seems to work.
This is a complete working program with the class and a test
implementation. In real implementation it will be attached to a sockets
class where each thread will be a client connection to the server.
Messages will go from client thread -> main thread only.
The copy constructor and assignment operator have been declared private
cause they just don't work.
For just a synchronization wrapper around std::queue it seems to be a
more complicated than it has to be.
You don't need an explicit flush method. Just have the dtor for
ThreadQueue delete any remaining queued buffers.
::RemoveHead has 4 exit conditions.
1 normal (message returned)
4 shutdown (normal end of file)
You need to communicate that to the caller. Either through
separate status and buffer return variables, or use static
const strings for conditions 2, 3, and 4.
It is my understanding that the caller can determine this on it's own
If a message has been returned, it's either 1 or 4.
If a message is NULL, but not isShutdown(), it's 2.
If no message has been returned and isShutdown() it's 3.
Case 4 is special, and I had planned on a clean shutdown to have the caller
finish processing the messages in the queue, once the messages have been all
processed, it's the same as 3.
Don't you feel this is adequate?
Doing everything with a semaphore won't hack it. You need
an additional event object to communicate conditions 3 or 4.
::RemoveHead should wait mulitple for either to be signaled.
You shouldn't return 4 if there's any string buffers and
can only return a buffer if you consumed a semamphore signal.
So you might have to add a wait single w/ timeout=0 to force
that in that case.
There was originally in the class I modified another semephore that did the
terminate. However, when this semaphore was caught it issued a Terminate
Thread. I realized that this would be caught in my main thread, not my
worker thread, and would terminate the wrong thread, which is why I removed
it as a semaphore and introduced the shutdown flag.
- Prev by Date: Re: posix threads, pthread_yeld
- Next by Date: Re: Critique ThreadQueue class please
- Previous by thread: Re: Critique ThreadQueue class please
- Next by thread: Re: Critique ThreadQueue class please