Problem: Creation of a modless CDialog in a thread.

[Paul McKenzie]

but I do not agree with the fact that MT programming is hard to debug. It’s like everything else: It requires being rigorous.

Tell that to the many companies that will refuse to hire any programmer that doesn't know how to develop/debug MT apps, regardless of how much those programmers may be wizards at developing/debugging single-threaded apps.

Regards,

Paul McKenzie

[MikeAThon]

In MFC, creation of a dialog (indeed, the creation of ANY window) involves the temporary installation of a hook (a CBT hook, to be precise), in order to hook into the window creation process and to link the CWnd object to the HWND window. This allows MFC to handle some of the very earliest messages posted to the window, such as WM_NCCREATE, since otherwise the messages would not yet be linked into the MFC message map system via the CWnd object.

It comes as no surprise that back-to-back posting of PostThreadMessage might interfere with this process, although I cannot now think of a reason that the call to CWnd::Create might block.

Anyway, as explained in the link given by D_Drmmr, and as also explained in the docs for PostThreadMessage, it's almost always a mistake to call PostThredMessage to a thread that displays any visible UI. The reason involves loss of such messages at any time when the UI is in a modal message loop, such as during re-sizing or dragging operations. So it's probably best to go with your re-design, where all UI is handled by a single thread.

Mike

[Cariboo42]

So, I'm curious what makes you say that MT programming is not hard to debug? Which tools/methods do you use?

First of all, I think a good idea is to use a method to design applications.
Personally I use UML with a lot of sequence diagrams for multi-threaded project, with every possible case. This prevents from architecture problems and allows to clearly identify all cases (normal processing, error processing...).

Then, simply code what the diagrams shows with rigour. Check all return values, correctly manage all error cases... Just like for memory management: You check allocations, buffer sizes, free all allocated memory... MT coding is just the same.

Working this way, MT bugs are very rare and easy to found: Just check your design to find out what happen or if a case is not missing... Check that the code corresponds to the design.

Another tool I use is a log-file object that also log timestamp and thread id. With the possibility to disable parts of the logs that are not significant and can alter the MT behaviour. (My logs are organized in log domains. Generally one log domain for one class.)
Personally, I rarely use log-file for debugging. It is more a way for me to control the application behaviour during tests.

At last, if a problem is not strictly reproducible, it is always possible to automate application then analyze logs after lunch or in the morning.
I encountered one random bug once in the past, I work in a company that develop a client-server survey software with a mass multi-threaded server (threads for address research and automatic phone calls, for clients requests management, for answers analysis and recording, for live database analysis, and more). The problem happened once a week in normal process and every night with our automated process. After two weeks of investigation, the bug was not due to MT but to a memory allocation problem: a bug in a buffer size computation lead to a very rare buffer overflow and other data to be corrupted.

It is the reason why I do not think MT development is not harder to code and develop than every thing else. We just need to be rigorous in our work.
It’s just my feeling about it and your experience can be different.

[Cariboo42]

Anyway, as explained in the link given by D_Drmmr, and as also explained in the docs for PostThreadMessage, it's almost always a mistake to call PostThredMessage to a thread that displays any visible UI. The reason involves loss of such messages at any time when the UI is in a modal message loop, such as during re-sizing or dragging operations. So it's probably best to go with your re-design, where all UI is handled by a single thread.

Ok. Now, I have a better understanding of how Windows manages messages.
I’ll redesign my application that way this week-end. Fortunately not a big redesign.

Thanks to all.
(and sorry for my bad English. Hope it didn’t hurt your eyes too hard )

[MikeAThon]

Personally I use UML with a lot of sequence diagrams [emphasis added by Mike] for multi-threaded project, with every possible case. This prevents from architecture problems and allows to clearly identify all cases (normal processing, error processing...).
...It is the reason why I do not think MT development is not harder to code and develop than every thing else. We just need to be rigorous in our work.

One possible problem with this approach, and one reason why multi-threaded coding/debugging is much more difficult than its singly-threaded counterpart, is that execution of multi-threaded code, by multiple processors, is non-deterministic and most definitely NOT sequential. Sequence diagrams, which emphasize sequential processing, are in my mind of little help when it comes to multi-threaded development.

One man's view, anyway.

Mike

[Paul McKenzie]

It is the reason why I do not think MT development is not harder to code and develop than every thing else.

Then again, why do most in the industry will not hire programmers who has no MT experience when MT experience is required, regardless of the other programming experience the programmer may have?

To these companies, it is imperative that the person knows, not in passing, but have a wealth of knowledge of MT design, debugging, and maintenance. And again, you can have decades of "single-threaded" experience, you just will not make it in the real MT world on single-thread experience and a week or two of reading a book.

Usually, you gain MT experience if you're in a company that currently have ST apps that are being converted to MT due to various circumstances. Otherwise, and this is in the areas of the United Statesd I have been to, it is very difficult to find anyone willing to hire ST programmers to step into a MT job just like that.

The obvious reason for this is that MT programming is, to put it simply, not easy or even easily grasped by many experienced ST coders. It does require experience, knowing which synchronization objects to use and when, diagnosing errors such as race conditions, what are MT safe constructs and which are not, etc. Not small topics at all...

Regards,

Paul McKenzie