Thread Colsing Problem
-
I have created Thread Using AfxBeginThread, to diaply continous text on dialog bar, while if I close entire application or interrupt the application i gets Memory leakage, please help.
-
I have created Thread Using AfxBeginThread, to diaply continous text on dialog bar, while if I close entire application or interrupt the application i gets Memory leakage, please help.
-
I have created Thread Using AfxBeginThread, to diaply continous text on dialog bar, while if I close entire application or interrupt the application i gets Memory leakage, please help.
How do you cancel the thread? This doesn't seem to be a suitable solution for updating text. Consider using a timer, CWnd::SetTimer(), to update the text. -- Roger
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"No one remembers a coward!" - Jan Elfström 1998
"...but everyone remembers an idiot!" - my lawyer 2005 when heard of Jan's saying above -
How do you cancel the thread? This doesn't seem to be a suitable solution for updating text. Consider using a timer, CWnd::SetTimer(), to update the text. -- Roger
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"No one remembers a coward!" - Jan Elfström 1998
"...but everyone remembers an idiot!" - my lawyer 2005 when heard of Jan's saying above^^ yep if possible use a timer... otherwise by using a thread: load: ThreadRef = AfxBeginThread(Thread, ¶ms, THREAD_PRIORITY_BELOW_NORMAL, 0, CREATE_SUSPENDED); disable auto delete: ThreadRef->m_bAutoDelete = false; start Thread: ThreadRef->ResumeThread(); then use a global variable to signalize the thread to exit (in Thread func)
if(params->pDlg->m_WantExit){ return 1; }and use a own method in the main function to clean up the threads, calld before ending, and also wait till they end.do{ Sleep(1); //jump to thread GetExitCodeThread(ThreadRef->m_hThread,&ExitCode); }while(ExitCode == STILL_ACTIVE);this makes sure that the thread gets canceled correct on end of the main function. -
^^ yep if possible use a timer... otherwise by using a thread: load: ThreadRef = AfxBeginThread(Thread, ¶ms, THREAD_PRIORITY_BELOW_NORMAL, 0, CREATE_SUSPENDED); disable auto delete: ThreadRef->m_bAutoDelete = false; start Thread: ThreadRef->ResumeThread(); then use a global variable to signalize the thread to exit (in Thread func)
if(params->pDlg->m_WantExit){ return 1; }and use a own method in the main function to clean up the threads, calld before ending, and also wait till they end.do{ Sleep(1); //jump to thread GetExitCodeThread(ThreadRef->m_hThread,&ExitCode); }while(ExitCode == STILL_ACTIVE);this makes sure that the thread gets canceled correct on end of the main function.I suggested a timer in the same thread since you will eventually get a deadlock situation if you update GUI objects from other threads. The timer solution is also more straight forward. Besides, your thread handling suggestion contains a lot of errors and bad solutions that should not be recommended someone. 1. You left out the information what 'params' really is. Usually you pass the 'this' pointer and call a static member function that converts the void pointer. 2. You set CWinThread::m_bAutoDelete to FALSE without deleting the object returned by AfxBeginThread which will create a memory leak. 3. You're calling GetExitCodeThread in a loop where you think your thread will terminate by a call to ::Sleep(), even if you set the priority of the thread below normal. It will terminate eventually, but your main thread has higher priority. The comment that a call to ::Sleep() will execute your secondary thread is very wrong: there's no guarantee that your thread will be executed. Even the argument to ::Sleep() reveals a lot. The correct way to do it is to wait on the thread handle, CWinThread::m_hThread, with a call to e.g. ::WaitForSingleObject(). For more information about how to do multithreading, read here[^]. -- Roger
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"No one remembers a coward!" - Jan Elfström 1998
"...but everyone remembers an idiot!" - my lawyer 2005 when heard of Jan's saying above -
I suggested a timer in the same thread since you will eventually get a deadlock situation if you update GUI objects from other threads. The timer solution is also more straight forward. Besides, your thread handling suggestion contains a lot of errors and bad solutions that should not be recommended someone. 1. You left out the information what 'params' really is. Usually you pass the 'this' pointer and call a static member function that converts the void pointer. 2. You set CWinThread::m_bAutoDelete to FALSE without deleting the object returned by AfxBeginThread which will create a memory leak. 3. You're calling GetExitCodeThread in a loop where you think your thread will terminate by a call to ::Sleep(), even if you set the priority of the thread below normal. It will terminate eventually, but your main thread has higher priority. The comment that a call to ::Sleep() will execute your secondary thread is very wrong: there's no guarantee that your thread will be executed. Even the argument to ::Sleep() reveals a lot. The correct way to do it is to wait on the thread handle, CWinThread::m_hThread, with a call to e.g. ::WaitForSingleObject(). For more information about how to do multithreading, read here[^]. -- Roger
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"No one remembers a coward!" - Jan Elfström 1998
"...but everyone remembers an idiot!" - my lawyer 2005 when heard of Jan's saying aboveWell I left several part out, thats true. - I thought its well known whats able to fill 'params' with - the Threadobject would be deleted after the loop jumps out, what happens when the thread has ended (I didnt write it, ok). - that the Sleep() is no 100% secure statement for a threadchange ist true - to secure the application for deadlocks, there are several locking mechanism possible so secure shared variables. - WaitForSingleObject has the problem that it locks up the application that calls it if used tirect in a window creating code, thats why i used a loop. Well Im not a code guru, dont think Im one and also theres every time someone that knows more than me :)
-
Well I left several part out, thats true. - I thought its well known whats able to fill 'params' with - the Threadobject would be deleted after the loop jumps out, what happens when the thread has ended (I didnt write it, ok). - that the Sleep() is no 100% secure statement for a threadchange ist true - to secure the application for deadlocks, there are several locking mechanism possible so secure shared variables. - WaitForSingleObject has the problem that it locks up the application that calls it if used tirect in a window creating code, thats why i used a loop. Well Im not a code guru, dont think Im one and also theres every time someone that knows more than me :)
My first post I suggested an alternative design solution for the OP, since I'm under the impression that he had selected the wrong solution for the problem. You don't paint the walls with a hammer. In my second post I was really trying to help you to avoid troubles in your way of doing multithreaded applications.
spielehelfer wrote:
- I thought its well known whats able to fill 'params' with - the Threadobject would be deleted after the loop jumps out, what happens when the thread has ended (I didnt write it, ok).
Ok, so noted. A word of caution though: don't assume that the person you're trying to help is aware of things you consider 'common knowledge'. In my opinion it's hard enough to help someone while guessing their level of expertise.
spielehelfer wrote:
- that the Sleep() is no 100% secure statement for a threadchange ist true
True, in fact it might be quite the opposite: it's almost 100% wrong to use ::Sleep() in this situation. ::Sleep(0) would make a little more sense but it would still not be quite right. Read the timing section [^] of Joe Newcomer's article and you will know why afterwards.
spielehelfer wrote:
- to secure the application for deadlocks, there are several locking mechanism possible so secure shared variables
:suss: A "deadlock" and "corrupt data due to multiple threads accessing the same data" are two very different problems, but both are related to multithreading. Protecting shared data is often called "thread synchronization". You cannot prevent deadlocks by the use of thread synchronization; you may, however, cause a deadlock by improper use of thread synchronization.
spielehelfer wrote:
- WaitForSingleObject has the problem that it locks up the application that calls it if used tirect in a window creating code, thats why i used a loop
If it's the blocking part you worry about I can tell you that your loop solution is worse. (Calling ::Sleep()!) :-> It really doesn't matter: you should use ::WaitForSingleObject(), or ::WaitForMultipleObjects(), for multiple reasons (the ones below at the top of my head): 1. you can set a timeout 2. t
