MFC Fragility to multiple threads
-
Hi, The behaviour of MFC when writing Multi Threaded Applications, be it as simple as implementing a Progress Bar, still throws surprises at me. Why is MFC so fragile in this aspect. A Progress Barr is not an object we can Set, no, we have to write 'Inside Out' Code, the Dialog starts a Worker Thread, to do the task, and update the Dialog. The two threads then can only communicate via the SDK SendMessage(...) Now, I admit, I use MFC42. Maybe later MFC libraries have better implementations. Can anyone shed any light on this ? Regards, :)
Bram van Kampen
-
Hi, The behaviour of MFC when writing Multi Threaded Applications, be it as simple as implementing a Progress Bar, still throws surprises at me. Why is MFC so fragile in this aspect. A Progress Barr is not an object we can Set, no, we have to write 'Inside Out' Code, the Dialog starts a Worker Thread, to do the task, and update the Dialog. The two threads then can only communicate via the SDK SendMessage(...) Now, I admit, I use MFC42. Maybe later MFC libraries have better implementations. Can anyone shed any light on this ? Regards, :)
Bram van Kampen
This has not changed and will probably never change:
Multithreading: Programming Tips[^]
For size and performance reasons, MFC objects are not thread-safe at the object level, only at the class level.
For GUI objects, MFC is mainly a wrapper for the Windows API calls. When modifying GUI elements the corresponding API messages are sent and processed by the control's message loop. So there is no difference between MFC and API applications when changing a GUI element from within a worker thread: Both have to send messages. However, to send a message from another thread,
PostMessageshould be used instead ofSendMessageto inject the message into the queue and process it later by the thread owning the control. From my point of view using messages to update GUI controls is even simpler than using synchronisation and locking classes for shared objects. -
Hi, The behaviour of MFC when writing Multi Threaded Applications, be it as simple as implementing a Progress Bar, still throws surprises at me. Why is MFC so fragile in this aspect. A Progress Barr is not an object we can Set, no, we have to write 'Inside Out' Code, the Dialog starts a Worker Thread, to do the task, and update the Dialog. The two threads then can only communicate via the SDK SendMessage(...) Now, I admit, I use MFC42. Maybe later MFC libraries have better implementations. Can anyone shed any light on this ? Regards, :)
Bram van Kampen
An oldie-goldie resource: [Newcomer's "Threads and Processes series"](http://www.flounder.com/mvp_tips.htm#hreads and Processes series).
-
Hi, The behaviour of MFC when writing Multi Threaded Applications, be it as simple as implementing a Progress Bar, still throws surprises at me. Why is MFC so fragile in this aspect. A Progress Barr is not an object we can Set, no, we have to write 'Inside Out' Code, the Dialog starts a Worker Thread, to do the task, and update the Dialog. The two threads then can only communicate via the SDK SendMessage(...) Now, I admit, I use MFC42. Maybe later MFC libraries have better implementations. Can anyone shed any light on this ? Regards, :)
Bram van Kampen
If it has issues, you're probably doing it wrong. The GUI should really only be updated directly from a single thread. If you have any asynchronous updates (i.e. from an independent thread), they should remain asynchronous. There are asynchronous communication methods within the Windows frameworks, use them.
-
An oldie-goldie resource: [Newcomer's "Threads and Processes series"](http://www.flounder.com/mvp_tips.htm#hreads and Processes series).
Well CPalini, I am familiar with this site, and, although I do not always agree with it's theology, to coin a phrase, have found many useful topics there over time. I am writing a System where Dialogs Time Out, after a period of Non Activity. What's more, it collapses the whole stack of Dialogs, going back to Page1. That all works. As a Convenience to the User, I was going to implement a small Progress Control in the bottom LH Corner to show how many mins or secs left. I would have expected that a DialogBox, with No Activity whatsoever, other than keying or mouseing (i.e. Not in a Lengthy Calculation) should be able to receive messages, to give an indication of time left. The system is supposed to be in an Idle Loop It's not part of the functionality that will make the system work, it's part of the GUI spark that contributes to make it sellable.
:) :) Bram van Kampen
-
Hi, The behaviour of MFC when writing Multi Threaded Applications, be it as simple as implementing a Progress Bar, still throws surprises at me. Why is MFC so fragile in this aspect. A Progress Barr is not an object we can Set, no, we have to write 'Inside Out' Code, the Dialog starts a Worker Thread, to do the task, and update the Dialog. The two threads then can only communicate via the SDK SendMessage(...) Now, I admit, I use MFC42. Maybe later MFC libraries have better implementations. Can anyone shed any light on this ? Regards, :)
Bram van Kampen
The GUI elements should only be accessed from the main GUI thread. Accessing from another thread sometimes but not always results in an exception. As the others have said, use PostMessage to trigger an update in the GUI thread.
-
If it has issues, you're probably doing it wrong. The GUI should really only be updated directly from a single thread. If you have any asynchronous updates (i.e. from an independent thread), they should remain asynchronous. There are asynchronous communication methods within the Windows frameworks, use them.
Well, Is this a Fragility a feature of MFC, and from how it wraps the SDK functions, or, is this a Feature that is Central to Windows, (i.e. the SDK suffers from the same problem) I have read several articles about this, and, the Gist is that it is always unsafe to communicate between two threads. This is clearly to conservative, Microsoft manages it quite well in for instance their MS Office Products. Thanks for your Interest. :)
Bram van Kampen
