Multi Threading
Derek Baker
question I have is what would be the effect of not doing it that way?
--
Derek
Scott McPhillips [MVP]
> I understand that you should put all the GUI in the main thread. The
> question I have is what would be the effect of not doing it that way?
>
Interthread communication and synchronization is difficult and
error-prone. Introducing those difficulties between GUI objects
needlessly complicates the design and adds opportunities for error.
Keep thread functions and inter-thread communications as simple as
possible to minimize bugs.
--
Scott McPhillips [VC++ MVP]
Robert Scott
As a follow-on question, what would be the repercussions of doing
this: a worker thread calls SetWindowText for a window whose window
proc belongs to the main UI thread. I try to avoid doing this on
general principles, but on occasions when I have done it accidentally,
it worked just fine. Is this type of thing safe, or was I just lucky?
-Robert Scott
Ypsilanti, Michigan
(Reply through newsgroups, not by direct e-mail, as automatic reply address is fake.)
Scott McPhillips [MVP]
>>Interthread communication and synchronization is difficult and
>>error-prone. Introducing those difficulties between GUI objects
>>needlessly complicates the design and adds opportunities for error.
>>Keep thread functions and inter-thread communications as simple as
>>possible to minimize bugs.
>
>
> As a follow-on question, what would be the repercussions of doing
> this: a worker thread calls SetWindowText for a window whose window
> proc belongs to the main UI thread. I try to avoid doing this on
> general principles, but on occasions when I have done it accidentally,
> it worked just fine. Is this type of thing safe, or was I just lucky?
Accessing a window that belongs to the main thread sends a message that
must be handled by the main thread. In itself this is safe and
guaranteed to work. But if the main thread is busy or blocked then the
sending thread is suspended and has to wait. This kind of defeats the
purpose of having a second thread, and it can cause a deadlock if the
owner thread is suspended waiting for the worker thread to exit.
Lucian Wischik
>As a follow-on question, what would be the repercussions of doing
>this: a worker thread calls SetWindowText for a window whose window
>proc belongs to the main UI thread. I try to avoid doing this on
>general principles, but on occasions when I have done it accidentally,
>it worked just fine. Is this type of thing safe, or was I just lucky?
Obviously it's not thread safe! That's because SetWindowText will
block on the hwnd's thread, but at the same time the main thread might
conceivably be blocking on your worker thread. -- result: deadlock.
Here (below) is a small example that exhibits the problem. The worker
thread calls "SetWindowText" every 500ms. But as soon as you click the
left button, I programmed the main thread to block on the worker
thread, and hence the entire application freezes. The technique I used
to block on the worker thread is unlikely in practice -- in practice,
instead, you'll use far more insidious and hard-to-debug modes of
blocking.
--
Lucian
#include <windows.h>
HINSTANCE hInstance;
HANDLE hAbort;
// hAbort is an asynchronous signal to tell the worker thread to
// eventually abort.
CRITICAL_SECTION critsec;
// critsec is something that the worker thread enters, and stays
// in for its entire existence. Therefore any other thread who
// tries to acquire the critsec will end up blocking on the
// worker thread.
DWORD WINAPI ThreadProc(void *param)
{ HWND hwnd = (HWND)param;
EnterCriticalSection(&critsec);
for (int i=0; WaitForSingleObject(hAbort,500)!=WAIT_OBJECT_0; i++)
{ char c[20]; wsprintf(c,"%i",i);
SetWindowText(hwnd,c);
}
LeaveCriticalSection(&critsec);
return 0;
}
LRESULT CALLBACK WndProc(HWND hwnd,UINT msg,WPARAM wParam,LPARAM
lParam)
{ switch (msg)
{ case WM_LBUTTONDOWN:
{ EnterCriticalSection(&critsec);
MessageBox(hwnd,"The main window is in the
critsec","critsec",MB_OK);
LeaveCriticalSection(&critsec);
} break;
case WM_DESTROY:
{ PostQuitMessage(0);
} break;
}
return DefWindowProc(hwnd,msg,wParam,lParam);
}
int WINAPI WinMain(HINSTANCE h,HINSTANCE,LPSTR,int)
{ hInstance=h;
WNDCLASS wc; ZeroMemory(&wc,sizeof(wc));
wc.style = CS_HREDRAW|CS_VREDRAW;
wc.lpfnWndProc = WndProc;
wc.hInstance = hInstance;
wc.hCursor = LoadCursor(NULL,IDC_ARROW);
wc.hbrBackground = (HBRUSH)GetStockObject(GRAY_BRUSH);
wc.lpszClassName= "LucianHasClass";
RegisterClass(&wc);
HWND hwnd = CreateWindow("LucianHasClass","A
Window",WS_VISIBLE|WS_OVERLAPPEDWINDOW,CW_USEDEFAULT,CW_USEDEFAULT,CW_USEDEFAULT,CW_USEDEFAULT,NULL,0,hInstance,0);
InitializeCriticalSection(&critsec);
hAbort=CreateEvent(0,FALSE,FALSE,0);
DWORD tid; HANDLE hThread =
CreateThread(0,0,ThreadProc,hwnd,0,&tid);
MSG msg; while (GetMessage(&msg,0,0,0))
{ TranslateMessage(&msg);
DispatchMessage(&msg);
}
SetEvent(hAbort);
WaitForSingleObject(hThread,INFINITE);
DeleteCriticalSection(&critsec);
CloseHandle(hThread);
CloseHandle(hAbort);
return 0;
}
Robert Scott
<scot...@mvps.org.nowhere> wrote:
>Accessing a window that belongs to the main thread sends a message that
>must be handled by the main thread. In itself this is safe and
>guaranteed to work. But if the main thread is busy or blocked then the
>sending thread is suspended and has to wait. This kind of defeats the
>purpose of having a second thread, and it can cause a deadlock if the
>owner thread is suspended waiting for the worker thread to exit.
Ah, so if I have to do this sort of thing, I might be better to call
PostMessage with the WM_SETTEXT message, taking care that the string
referenced will persist in static memory long enough for the main
thread to handle the message...
Stephen Kellett
<no-...@nowhere-q7x.com> writes
>As a follow-on question, what would be the repercussions of doing
>this: a worker thread calls SetWindowText for a window whose window
>proc belongs to the main UI thread. I try to avoid doing this on
>general principles, but on occasions when I have done it accidentally,
>it worked just fine. Is this type of thing safe,
No, depending on your application you run the risk of Deadlock. Never
use SendMessage to send from one thread to another, use PostMessage
instead. SetWindowText uses SendMessage.
Stephen
--
Stephen Kellett
Object Media Limited http://www.objmedia.demon.co.uk
RSI Information: http://www.objmedia.demon.co.uk/rsi.html
Ralf Buschmann
wrote:
>Obviously it's not thread safe!
Only if you design it to be so, IMHO :-) Just remember that the purpose
of a message loop is to process messages and nothing else and you'll be
fine.
Ralf.
Derek Baker
not to implement multi-threading in my app:)
--
Derek
Jussi Jumppanen
>
> I understand that you should put all the GUI in the main thread. The
> question I have is what would be the effect of not doing it that way?
Every Windows application has built in thread locking in their message
queue, provided free of charge by Win32.
Now consider the case where you main process traps a windows message,
at starts a thread which then sends a message to the queue that started
the thread. In this situation, by windows design your application will
hang. This is the exact reason why functions like PostThreadMessage
exist in the Win32.
Jussi Jumppanen
Author of: Zeus for Windows (All new version 3.90 out now)
"The C/C++, Cobol, Java, HTML, Python, PHP, Perl programmer's editor"
Home Page: http://www.zeusedit.com
Ralf Buschmann
<jus...@zeusedit.com> wrote:
>Now consider the case where you main process traps a windows message,
>at starts a thread which then sends a message to the queue that started
>the thread. In this situation, by windows design your application will
>hang.
Well, only if the main thread blocks on the newly created thread. I
wouldn't call this a Windows design issue but rather bad programming
practice. Just do not block on anything in a message loop. For instance,
instead of blocking on a thread handle, have the thread post a private
message when it's finished.
Ralf.
Markus Elfring
> question I have is what would be the effect of not doing it that way?
The document "How to Use Threads with Java™ (JFC/Swing)" has got
useful informations.
http://java.sun.com/docs/books/tutorial/uiswing/misc/threads.html