Is CWnd::GetSafeHwnd() and CWnd::m_hWnd ThreadSafe?

Question

I am facing numerous crashes on a application which is heavily multi-threaded.

Reading these MSDN page, technical note and this article on TLS, I have understood that CWnd objects are mapped to HWND in the Thread Local Storgae (TLS, which is a thread dependendent memory access).

I was going to decouple everything that looks like CWnd thread-remote access, and transform it into HWND references and then use ::PostMessage as communication port.

But one of my colleagues really insisted that I just keep the CWnd* in the foreigner threads, adopt the ::PostMessage policy ok, but use CWnd::GetSafeHwnd() or the pMyCWnd->m_hWnd in the foreign threads so as to recover the native HWND.

I have been arguing that nowhere I have seen that the GetSafeHwnd() is threadsafe, and that the CWnd objet being in the TLS, it's value in another thread is different.

I am wrong ? The MSDN is clearly using the term Unexpected results.

What's your point of view, about calling CWnd::GetSafehwnd() or pMyCWnd->m_hWnd in outer threads from the creator thread ?

Do you have any MSDN documentation that states that this is safe or not.

Answer 1

CWnds are not mapped to HWNDs; HWNDs are mapped to CWnds, and this happens on a per-thread basis. The CWnd object is not in TLS (how would that work?) but temporary CWnd objects are created per-thread.

Accessing a temporary CWnd object from the wrong thread is definitely a bad idea (for the reasons described by Mark Ransom).

However, if you have a permanent CWnd object (representing the main window of your app, say) then, once it is created, there is no problem at all in accessing the m_hWnd member from any thread. It's just a value in memory that never changes.

If this troubles you (because it's not explicitly documented) then simply make a copy of the HWND and let the threads access that.

P.S. Here's the article you linked to in English.

Answer 2

GetSafeHwnd is simply a wrapper that checks if this is NULL, returns m_hWnd if not and NULL if it is. It won't be any more threadsafe than m_hWnd itself.

When you create a temporary CWnd*, MFC will destroy it at a point it considers safe, such as the next pass through the message loop. If you have multiple threads using MFC then your temporary object could get destroyed while you're still using it. Nothing you can do from your thread will detect this error.

Answer 3

If you have a multithreaded application where multiple threads are all trying to access HWNDs at once, it sounds to me like you have a design problem. Can't you constrain your threads to doing computation, and handle UI concerns on the main thread? That's the typical design of a good multithreaded app.