Calling a function in AfxBeginThread

[eclessiastes]

I have the code:

void go(CMFCApplication1Dlg * pdlg)
{
pdlg->listcontrol1.InsertItem(0, "Row1");
}

then i call it in thread

void CMFCApplication1Dlg::OnBnClickedButton3()
{
AfxBeginThread(go(this), NULL, THREAD_PRIORITY_NORMAL, 0, 0, NULL);
}

It doesn't work. Any idea how to make it work ? Thanks in advance!

[VictorN]

Well, better would be to forget what and how you wrote and instead learn about Using Worker Threads from the very begin!

[OReubens]

DO NOT attempt to create, modify, delete or basically do anything with windows on anything other than your main thread.


threads are for running non UI related code. UI related code belongs (strangely Obvious) in the main UI thread.
If you want to get somethign displayed from the worker thread, then POST (not send) a message to tell the main thread to do that work on behalf of the worker thread.

This is a fundamental premise in Windows. If you insist on updating the UI directly from a worker thread, expect to get crashes, deadlocks and all around strange behaviour at irregular moments during your program's run time.

[2kaud]

If you insist on updating the UI directly from a worker thread, expect to get crashes, deadlocks and all around strange behaviour at irregular moments during your program's run time.

Here, here! I'm still getting the nightmares from debugging some one's code that did this. The program used to randomly crash with memory exception problems. Very nasty.

This advice applies whether you use WIN32 APIs or MFC or another framework.

[Igor Vartanov]

Well, unlike MFC, Win32 API is completely thread safe. Though deadlocks are possible in any sort of threads, worker or GUI ones. And avoiding those is just a matter of understanding root cause.

[2kaud]

Well, unlike MFC, Win32 API is completely thread safe. Though deadlocks are possible in any sort of threads, worker or GUI ones. And avoiding those is just a matter of understanding root cause.

I've found issues with UI in WIN32 API code where more than one thread has been updating directly the UI. Changing the logic to that described by OReubens in post #3 cured the intermittent program crashes. Of course, in changing the code like that I may have fixed the underlying thread issues that caused the problem in the first place...........

IMO I would still recommend that the program design adheres to the principle outlined in post #3.

[Igor Vartanov]

I have the code:

then i call it in thread

void CMFCApplication1Dlg::OnBnClickedButton3()
{
AfxBeginThread(go(this), NULL, THREAD_PRIORITY_NORMAL, 0, 0, NULL);
}

It doesn't work. Any idea how to make it work ? Thanks in advance!

You should not call MFC windowed objects from thread other than the one those were created in. Add a string data member to your dialog, add a handler to a special window message that would call that InsertItem for list control. In your worker thread you should assign the string some value and post the message to dialog window using plain Win32 API PostMessage. No calls of MFC window object methods accross thread bounds.

[D_Drmmr]

...Add a string data member to your dialog, add a handler to a special window message that would call that InsertItem for list control. In your worker thread you should assign the string some value and post the message to dialog window using plain Win32 API PostMessage. No calls of MFC window object methods accross thread bounds.

...and synchronize access to the string data member using a Critical Section.

[OReubens]

Well, unlike MFC, Win32 API is completely thread safe. Though deadlocks are possible in any sort of threads, worker or GUI ones. And avoiding those is just a matter of understanding root cause.

Well... I guess it depends on what you would call "thread safe". The answer is not as clear cut as it seems.

from a pure technical POV. Yes, you are right...

IN practice things are a bit more complex, because the UI type API's typically expect that you use a window handle ONLY on the same thread that created the window handle in the first place, which also needs to be the very same thread where the window procedure will be called on.

Does that invalidate the "thread safety" assumption ? No, because it is possible to have more than one UI thread. But really, this is a whole other can of worms you're opening if you insist on needing more than 1 UI thread. So yes, the API's are technically safe because you can call the same UI related function from 2 UI threads at the same time PROVIDED each thread is handling an window that "belongs to" its own thread.

--
And yes, there are a few cases where you can seemingly get this to work reliably for all flavours of Windows. "the magic" is in the way SendMessage() works.
Note the remarks on there however "The sending thread is blocked until the receiving thread processes the message. "
With proper care you can make this to work, but later changes can easily disrupt the assumptions made to get it to work. It's much better to simply approach your app from the premise that you shouldn't touch the UI directly from a worker thread.
This in and of itself is one of the most common "bugs" I'm finding in software I'm evaluating.

[Igor Vartanov]

Well... I guess it depends on what you would call "thread safe". The answer is not as clear cut as it seems.

from a pure technical POV. Yes, you are right...

IN practice things are a bit more complex, because the UI type API's typically expect that you use a window handle ONLY on the same thread that created the window handle in the first place, which also needs to be the very same thread where the window procedure will be called on.

All Windows UI API is built mostly on sending messages to controls, and one really critical thing you are to remember about is "SendMessage blocks caller thread". All the other APIs dealing with window handles are perfectly thread safe, maybe with a few rare exceptions related to message queue pumping specifics.

All the said above gives us totally different picture. Once again, UI related Win32 API is thread safe by design, maybe with a few rare exceptions. And all troubles with MFC window objects have nothing to do with Win32 API, being stipulated by the very specific way how MFC maps native window handles to corresponding MFC CWin-derived objects.

[OReubens]

All the other APIs dealing with window handles are perfectly thread safe, maybe with a few rare exceptions related to message queue pumping specifics.

well... the "problem" there is that some API functions will send messages even though the call itself doesn't seem like it does.
The most Obvious one of that is Get/SetWindowText()

[eclessiastes]

The program is working fine right now, it fills the list control without blocking the interface, why is it needed to use send messages instead of controlling the elements from thread ? I've never experienced crashes that's why i'm asking

[Igor Vartanov]

well... the "problem" there is that some API functions will send messages even though the call itself doesn't seem like it does.
The most Obvious one of that is Get/SetWindowText()

And? The call you mentioned has no chance to be deadlocked as the called thread is not going to acquire any resource from caller thread during setting window text. So it's what I call perfectly thread safe. Same thing with most of other similar APIs.

[VictorN]

send messages[/hl] instead of controlling the elements from thread ?

Wrong! A worker thread has to post messages to the main UI thread, not to send!
Haven't you read the J.Newcomer's essay about Using Worker Threads?