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 ? |