Prev: Who could give me an example for enumerate brush?
Next: What forms the basis of Skinning ?
From: Senge on 5 Feb 2010 07:48
Hi Gurus:
in main thread , i have

void MainProc()
{
DWORD dwThreadID;
HANDLE hThread = CreateThread(NULL, 0,
(LPTHREAD_START_ROUTINE)ReadThread, this, 0, &dwThreadID);
WaitForSingleObject( hThread , INFINITE );
}
DWORD ReadThread(void *pVoid)
{
Do somthing...
}
I suppose the thread will begin right after CreateThread, and the
MainProc will block until the ReadThread is finished. but it seems i'm
wrong. there is a dead block.

what is the scenario should be?


Jeff Hu


From: David Lowndes on 5 Feb 2010 08:51
>in main thread , i have
>
>void MainProc()
>{
> DWORD dwThreadID;
> HANDLE hThread = CreateThread(NULL, 0,

Remove the cast below - it might be hiding an error:

>(LPTHREAD_START_ROUTINE)ReadThread, this, 0, &dwThreadID);
> WaitForSingleObject( hThread , INFINITE );
>}

>DWORD ReadThread(void *pVoid)

The thread function should be defined as WINAPI calling convention.

>I suppose the thread will begin right after CreateThread, and the
>MainProc will block until the ReadThread is finished. but it seems i'm
>wrong. there is a dead block.

Where - does the thread function get called - and does it exit?

Dave
From: Alexander Grigoriev on 5 Feb 2010 09:34
DOes your thread function access any windows, or call SendMessage?

"Senge" <v120160(a)gmail.com> wrote in message
news:8a75421c-0df9-42c7-8982-91a03739fe3e(a)l12g2000prg.googlegroups.com...
> Hi Gurus:
> in main thread , i have
>
> void MainProc()
> {
> DWORD dwThreadID;
> HANDLE hThread = CreateThread(NULL, 0,
> (LPTHREAD_START_ROUTINE)ReadThread, this, 0, &dwThreadID);
> WaitForSingleObject( hThread , INFINITE );
> }
> DWORD ReadThread(void *pVoid)
> {
> Do somthing...
> }
> I suppose the thread will begin right after CreateThread, and the
> MainProc will block until the ReadThread is finished. but it seems i'm
> wrong. there is a dead block.
>
> what is the scenario should be?
>
>
> Jeff Hu
>
>


From: Joseph M. Newcomer on 5 Feb 2010 10:02
See below...
On Fri, 5 Feb 2010 04:48:11 -0800 (PST), Senge <v120160(a)gmail.com> wrote:

>Hi Gurus:
>in main thread , i have
>
>void MainProc()
>{
> DWORD dwThreadID;
> HANDLE hThread = CreateThread(NULL, 0,
****
You have not said the context in which you are doing this. For example, if the thread
calls ANY function in the C runtime, this code is erroneous. You would have to call
_beginthread. If the thread calls ANY part of the MFC library, you would have to call
AfxBeginThread.
****
>(LPTHREAD_START_ROUTINE)ReadThread, this, 0, &dwThreadID);
****
Note that by adding the cast, you tell the compiler, "I know this is probably wrong, but
trust me, it is correct!"

Unfortunately, it is wrong. Putting the cast in such context is *ALWAYS* a coding error.
And in your case, the coding error masks a genuine error!
****
> WaitForSingleObject( hThread , INFINITE );
>}
>DWORD ReadThread(void *pVoid)
****
What in the world led you to suspect this was a correct thread function? The
documentation CLEARLY states for a ThreadProc that the prototype is
DWORD WINAPI ThreadProc(LPVOID lpParameter);
so why is it that you omitted the "WINAPI" which is ESSENTIAL for correct operation? And
why did you manually expand LPVOID to void*? Sure, they're the same, but why do something
in a clumsy fashion when there is a better way?
****
>{
> Do somthing...
>}
>I suppose the thread will begin right after CreateThread, and the
>MainProc will block until the ReadThread is finished. but it seems i'm
>wrong. there is a dead block.
****
Anything of the form
start thread...
wait for thread to finish...
is silly. You have created a very expensive and complex subroutine call! You can be
reasonably certain that if all you do is launch a single thread and wait for it
immediately that you have made a serious design error.

You can also safely assume that if the thread that launches the thread is the thread that
controls your GUI that you have made a serious design error, because you have not only
created an expensive and complex subroutine call, but you have actively defeated the
entire purpose of creating a thread in a GUI-based app, which is that the thread does not
block the GUI.
****
>
>what is the scenario should be?
****
Since you have coded some seriously bad code here, the first thing you have to do is fix
the code. Then you have to explain why in the world you would want to launch a thread and
immediately wait for it to finish.

Are you really sure the thread has finished? You have not actually presented evidence
that you know this has happened, such as "I set a breakpoint at the exit of the thread
function, and although the breakpoint is taken, the WaitFor still blocks"
joe
****
>
>
>Jeff Hu
>
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: David Ching on 8 Feb 2010 10:57
"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message
news:g2com55923rlh6fcja6s3qf3nek10rsrpe(a)4ax.com...
> Anything of the form
> start thread...
> wait for thread to finish...
> is silly. You have created a very expensive and complex subroutine call!
> You can be
> reasonably certain that if all you do is launch a single thread and wait
> for it
> immediately that you have made a serious design error.
>

I have done this - start a thread and use MsgWaitForMultipleObjects() to
wait for it to finish, while also getting messages that the user has clicked
the Close button to exit the app. When such a message is received, I can
signal the thread to terminate or terminate it forcefully in the worst case.
So yes, it is an expensive subroutine call but one that is abortable. Is
there a more efficient design pattern for an abortable subroutine call?

Thanks,
David

 |  Next  |  Last
Pages: 1 2
Prev: Who could give me an example for enumerate brush?
Next: What forms the basis of Skinning ?