Threads and send- /post messages. Help in design needed!

[Marc from D]

Hi!

I have a program that uses a worker-thread to communicate via RS232 with our controller-box. So far it works fine.

The worker sends messages using sendmessage(..) to the various message-handlers in my program. So the worker waits until the rest (the GUI) has finished it's job and then retrieves the next data from the RS232.

In result my GUI and the worker are working "either or", not virtually parallel. So the RS232 is slowed down by the GUI-operations.

I want to reduce this.

I tried PostMessage(..), but under special circumstances the operation of the GUI consumes more time than the worker needs to prepare the next message.

What would you try?
How do you send messages via PostMessage but avoid a traffic jam of messages?

Thanks!

Marc

[VictorN]

The simplest way to communicate between a worker-thread and a GUI - to PostMessage:

worker-thread:
CString* pstrData = new CString;
if(pstrData)
pstrData = .....// your data to post to GUI
::PostMessage/hWnd_GUI, MSG_MY_MSG, 0, (LPARAM)pstrData);
}GUI:// in your message handler:
CString* pstrData = (CString*)lParam;
if(pstrData)
{
// do what you want with received data
delete pstrData;
}
.......You can also use some structure to post the same way.

Also these Joseph M. Newcomer's articles:
Using Worker Threads (http://www.flounder.com/workerthreads.htm),
Using I/O Completion Ports for Cross-Thread Messaging (http://www.flounder.com/iocompletion.htm)
- could be useful

[Andreas Masur]

[Moved thread]

[Andreas Masur]

Take a look at the following FAQ (http://www.codeguru.com/forum/showthread.php?s=&threadid=231250)...

[Sam Hobbs]

I probably would not use messages, at least not to transfer data. I probably would use my own queue protected using either a mutex (::CreateMutex or MFC CMutex) or a critical section.

I admit I am not sure how I would indicate availability of data for the UI. An event (::CreateEvent or MFC CEvent) could be used to signal from the thread to the UI that data is available, which would make the work done very minimal when there is nothing to do. Perhaps a message would work well, but another possibility might be idle processing. Another possiblity is a timer. It might be entirely valid to update the UI at regular intervals, such as one second.

However if you are using the MFC Document/View Architecture, the worker thread should not be communicating with the view directly; it should be communicating with the document, which then uses UpdateAllViews as appropriate.

[Marc from D]

Thanks a lot!

As I'm only trying to optimize my appl. I'm not going to reinvent it. So the changes have to be small.

I tried (without success) the following:
I created a special counting function: Each PostMessage call in the worker just checks the counter, and when it is zero, it posts the message and counts one up.

Each Messagehandler just reduces the counter by one.
So the GUI can work and the Worker also.
The effect of it all is close to nothing.


I was analyzing in the meantime, why else the communication speed is low and found several Sleep() statements. I wonder what they do? They are typical "Sleep(5)"!!! I thought this would do nothing at all!?!

....Put together: Thanks a lot for your help! I'll post the additional questions in another thread.

Thanks!

Marc