This may or may not apply depending on your project, but using messages to pass data can be a bad idea when dealing with threads. The reason is the limit on the number of messages in a Windows message queue.
To circumvent this, I usually create a semaphore with a reasonable max count value. The thread that gets the data will increment the count for each data item received.
Next, have another worker thread that watches the semaphore for any indication of data and then processes it. Voila, no more messages! I've included a bit of pseudo-code:
//
// Our main RX thread.
//
void RX_THREAD()
{
// do something, wait for data
// got data, inform the other worker.
if ( got_data == true )
ReleaseSemaphore(hSemaphore, 1, NULL);
}
//
// The worker that receives the data.
//
void DATA_THREAD()
{
while ( true )
{
if ( WaitForSingleObject(sem, 500) == WAIT_TIMEOUT )
continue;
//
// The semaphore is signaled, get the data and process it.
//
// process data here.
}
At some point, you will want to decrement the semaphore's count, I generally do that in whatever routine passes the data between the threads, I find that the easiest way.
That's basically it, you can remove the need for the message queue this way and avoid overrun errors.
