C++, MFC Event Driven Multithreading Performance and Com+

I have written a Visual C++ (MFC) application that responds to an Active X event that reads data from a serial port. This data is received from an RF base station through the port which connects to multiple RF units. When the event is fired I process the data and return a reponse back through the port to the base station and to an RF unit. Each event is processed in sequence before the next event.  Some events require more processing time than others (such as database lookups). Since there may be data ready on the port while a current event is being processed, I tried a multithreading approach (AfxBeginThread) to speed up processing if one event takes longer than another. This approach is working but when two (or more) threads process at the same time the performance is degraded.

I have considered writing a Com+ application to handle the events simultaneously, but I'm not sure that the multithreading or marshaling will be any better. In a nut shell I need the events to be handled like a mini-server that can process requests in tandem and still provide better performance than the current sequential event handling that I am using. For compatability I need to stick with Visual C++ (6.0) and MFC and time is critical.

I would appreciate any input on the best performance options available. Is the Com+ approach viable? Does each call of the Com+ component within the main application create a separate process?

Who is Participating?
raed_hasanConnect With a Mentor Commented:

Since the modeless dialogs run in the main GUI thread, any lengthy processes here will block the main GUI thread and You
won't receive any new messages until You return from the lengthy process. In this case you have to use worker threads
instead. The worker threads can be part of the modeless dialog boxes and communicates only with those (they own and
control the worker threads). Your events can post messages to the modeless dialog windows (which in turn activates the
worker threads). This way it will work as you described.

The benefit with a modeless dialog is not so much for multitasking (if processing of messages are quick, it will seem
like multitasking though, but it won't work with long processing times) as it is for giving you a user interface and
feedback for your sub processes when you need it. In my programs they are invisible when all is working as it should and
only brought up when trouble shooting some connected hardware. And, as I said before, it will also give you a mechanism
to post/send messages directly to your tasks (objects based on a modeless dialog) working quietly in the background.

Many times I can break up the work for a lengthy process into smaller chunks. These chunks can be executed in the idle
handler (I have a mechanism to to add and remove tasks from the idle handler). This has the benefit that it runs in the
GUI thread which means that I can directly access GUI components and most of the time I don't need any special
synchronisation as is often necessary when multithreading.

Here are some examples of tasks which are based on modeless dialogs in my programs: Serial communication with RFID
readers, Serial communication with scales, serial communication with GPS receiver, Parallell IO (input and output to
other hardware), File importing (act when a file is dropped into a specific folder), Communication with external
programs, File handling and parsing in the background. Some of these use worker threads others do their work directly in
the main GUI thread either directly in the message handler or by adding a task to the idle handler.

Regards /Raed
When I have used an Active X component for serial communication I found that when executing one event from the active X
(say receive character) and in that event handler I called functions in the active x component (say set rts), any events
in queue would fire and those eventhandlers would run before the called function returned. I don't know if this is
vendor specific (Greenleaf comx) or technology specific (active x). I solved it by relaying the event with a PostMessage
to my self in order to re queue it and then do the actual work in the code for the message handler of the posted

I also use a modeless dialog as a base for my communications classes (and a lot of other classes) instead of a separate
thread (the active x does all neccessary threading anyway). This dialog contains an edit control which displays what is
happening in the serial communication state machine (only if the dialog is visible), like what characters are
received/sent, if checksum is OK, if a command has executed successfully and so on. The dialog also contains controls to
let the user change port settings if the app requires it. The dialog is normaly only visible when troubleshooting the
serial communication. Advantages with the modeless dialog, other than this visual feedback, is that it is a destination
for Post/Send messages and that it is working in the main GUI thread (no threading issues).

carlmahonAuthor Commented:
Thanks Raed - Very interesting approach using modeless dialog for multithreading, this may work for me but leads me to a brief follow up -

Assume - Event #1 from the active X has fired and I post a message to modeless box #1 and it is running a lengthy process before returning data to the port....
Event #2 is fired from the active X and I post a message to modeless box #2 (instead of a new thread), would both processes (modeless boxes) run in tandem and efficiently from the main GUI thread?
carlmahonAuthor Commented:
Thanks - The multitasking aspect was my main focus and you have provided me with substantial insight.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.