If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

AfxBeginThread

Something I am not being able to understand. I am using VC2005. In MFC I am creating threads repeatedly. The thread is basically doing nothing. Its an empty block. So, there should not be any memory leak. But I am seeing constant memory increase in the task manager. Here is my code.

Re: AfxBeginThread

if your main thread ends before all the created threads have completed, then you'll have a memory leak because all the child threads will be terminated (without allowing them proper cleanup) by the system.

a simple proof for this would be to add a 'long enough' Sleep() before your main thread ends. But this isn't a correct way to solve the actual problem.

If you create a thread, then you should have some form of synchronisation in your main thread that guarantees that ALL the worker threads have finished, before it exits to the system.

Note that if you call AfxBeginThread, then MFC will allocate a CWinThread object, if the thread isn't allowed to cleanup (or you don't do it in lieu of the normal thread cleanup), then you'll be leaking that object (at the least, potentially more).

Re: AfxBeginThread

Thank you for your comment. But my main thread never exits. The threads are created from OnInitDialog().

Originally Posted by OReubens

if your main thread ends before all the created threads have completed, then you'll have a memory leak because all the child threads will be terminated (without allowing them proper cleanup) by the system.

a simple proof for this would be to add a 'long enough' Sleep() before your main thread ends. But this isn't a correct way to solve the actual problem.

If you create a thread, then you should have some form of synchronisation in your main thread that guarantees that ALL the worker threads have finished, before it exits to the system.

Note that if you call AfxBeginThread, then MFC will allocate a CWinThread object, if the thread isn't allowed to cleanup (or you don't do it in lieu of the normal thread cleanup), then you'll be leaking that object (at the least, potentially more).

Re: AfxBeginThread

Originally Posted by carbuet

Stay constant.

That only proves that repeated calls to Sleep() do not leak. Who would doubt that?

Your code basically creates a new thread every 50 ms. On a very slow (or very busy) system, if the thread creation and tear down take more than 50 ms, the number of running threads (with whatever memory is allocated for them) will increase.
Could you add Thread count column to your task manager? Does it increase with time?

Re: AfxBeginThread

Will definitely prove that the program is behaving differently in different machines, possibly different OS/SP. The question is WHY? I compiled it in XP with VS2005, ran it in WIN7. The result is the same.

Re: AfxBeginThread

I'm going to repeat myself here...
each time you create a thread with AfxbeginThread, MFC allocates a CWinThread,
(the OS itself will allocate stack space for each thread)

you don't provide any synchronisation, so multiple threads may end up being active at the same time before they close and cleanup.
while the OS will cleanup the thread stack, the heap is not typically shrunk.
this means you'll be increasing the heap size of your program, and this memory isn't recovered until you exit.

Re: AfxBeginThread

Originally Posted by carbuet

Will definitely prove that the program is behaving differently in different machines, possibly different OS/SP. The question is WHY? I compiled it in XP with VS2005, ran it in WIN7. The result is the same.

* The Perfect Platform for Game Developers: Android
Developing rich, high performance Android games from the ground up is a daunting task. Intel has provided Android developers with a number of tools that can be leveraged by Android game developers.

* The Best Reasons to Target Windows 8
Learn some of the best reasons why you should seriously consider bringing your Android mobile development expertise to bear on the Windows 8 platform.