Designing Thread Class

I have a design question. Is it better to define separate classes for SENDING and RECEIVING. Or, is it better to define a single Thread class? I like the idea of a single Thread class because it is easier to share a queue which can be locked by mutex.

Design Option #1 (Separate):

mySendThread = new SendThread(); // Have thread properties and separate members

myRcvThread = new RcvThread(); // Have thread properties and separate members

Design Option #2 (Master):

Master thread -

Execute() 
{
    if (threadType == RCV_THREAD)
    {
        globalVar = new MasterThread(serialPortHandle);
    }
    while (开发者_JAVA技巧!Terminated)
    {
        if (threadType == RCV_THREAD)
        {
            if(globalVar) 
            {  
                // do work
            }
        }
        if (threadType == SND_THREAD)
        {
            tCountSnd = GetTickCount() / SND_THREAD_DELAY;
            if (tCountSnd != tCountSnd2) {
               tCountSnd2 = tCountSnd;
               if (globalVar) {
                   // do sending work
               }
            }
        }
     }
}

I think it's better to completely decouple the purpose or execution of a thread from the actual thread abstraction that you'll be using.

Make your thread class just a thin wrapper to allow you to start, stop, and join a thread. Have it take a functor object (or function pointer) in the constructor for the actual execution.

Or better yet, use one of the many available thread abstractions already out there instead of writing your own (boost::thread for one, but I bet whatever framework you're using already has a thread class).

I've designed a thread for communicating on the serial port (in Python, not C++, but it doesn't matter much) as follows:

There's a single thread and two queues - one for sent and one for received messages. The thread always listens (asynchronously) on both the serial port (for received data) and the sending queue (to send stuff the application asks to send).

1. If data arrived on the serial port, it's placed in the receive queue for the application's use
2. If the application placed data into the send queue, the thread sends it down the serial port

This design makes more sense to me because the single resource (the serial port) is held by a single thread, and not shared by two. Breaking it to several classes sounds like an overkill to me, since reading/writing from queues and reading/writing from the serial port is a trivial operation (naturally the serial port is wrapped in a convenient class - by the way I really recommend this class by Ramon De Klein)

Oh, and it works very well.

Regarding the queue to be shared .. wrap it in a separate class and implement the mutex handling there. Every thread class holds a reference to the queue wrapper and doesn't need to deal around with mutexes at all.

2nd choice is clearly a bad one. It is better to have 2 different classes , maybe you can have a base class which has common implementation. This is just an initial assessment please provide more information about your problem only then a good analysis of problem can be done