Close correcly the thread inside a dll

Question

4.50/5 (2 votes)

See more:

Hi I have an MFC dll (not so expert on that). There I create a thread, and it creates some variable.
When closing the application that variables need to be destroyed of course...but I can't catch the right moment to do that so I get "Detected memory leaks!".
I have some code t odo the clean at the end of the thread but I can't find a way to exit from a loop inside it before it is too late.

It seems that when Dll::CWinApp::ExitInstance is called is too late and the thread was already brutally terminated.
The same for Dll::CWinApp::OnFinalRelease (just to try the way).
I tried to create a class to manage the variables and the thread (inside the dll) but also this time when it comes the destructor of the class it is too late and the thread is alredy destroyed.

I don't like to terminate the thread using the main program because I like to leave the thread hidden (I mean it is not exported).

So finally I can't find the right way to trap some event to set my flag to exit from my thread correcly.

Any helps
Thanks

Posted 31-Mar-11 2:52am

Russell^'

Add a Solution

Comments

Guyverthree 31-Mar-11 9:15am

Is the thread message or event based ?

Or is it just going till the program quits ???

Russell^' 31-Mar-11 9:23am

HiIt is a simple worker thread (only file managing). It has to run always during the program run. Then I need to stop it correcly using a simple flag when the program stops.
I am trying to get some event from the CWinApp inside the dll (not the one in the exe, MFC application) to set that flag and wait that the thread exits itself, but it looks that everytime it is too late and the thread is already destroyed from somewhat before.

Guyverthree 31-Mar-11 9:39am

Have you tried creating three events, one for there is some work and the other two for a quit.
Then wait on all three and if you have work do some, but if you need to quit clean up the thread and then set the exit event so you know the thread has completed and cleaned up.

This structure would also be the same sort of thing if you message based the thread instead of event based it.

Sergey Alexandrovich Kryukov 31-Mar-11 13:35pm

It cannot be a solution because the application need to be closed at any moment, not only during wait state of the thread.
(Russel, I think you can ignore this idea.)
Also, OP has no problem with functionality -- the code is already working. OP wants to work cleanly in all phases of run-time.
--SA

Sergey Alexandrovich Kryukov 17-Apr-11 17:39pm

There is a comprehensive solution. I did not have enough time to discuss it, but today I did. Please see -- very interesting and robust.
--SA

Sergey Alexandrovich Kryukov 31-Mar-11 13:33pm

This is non-trivial question. The solution exist but is not easy (and trivial in .NET where a very cunning mechanism is added, the original solution was invented with C++ (exception seeding method) but is not portable). Some less universal (application-specific) solution might exist, but in this case you need to show your code (better in the smaller possible sample).

I vote 5 for the Question and using of a memory detection utility, which is a great sign of your serious approach.
--SA

Russell^' 1-Apr-11 3:56am

Thank you
Finally I found a way to export all the memory-cleaning into the distructor of the class I created to contain the thread. So the memory leaks is solved.
It remains a mistery how to detect the right moment to close myself the thread because I found that it can be 'terminated' at any time when the main window of the application is closed.
I think the only way can be now to receive a special call from the exe when it is receiving WM_CLOSE or something like that.
But in my case I don't like this because I want that the thread remains an hidden 'concept' into the dll so I don't like this needing. So I have adapted the code of the thread trying to avoid big problems ... but some little problems with the file managing still remains (I'll solve in future).
Regards

Sergey Alexandrovich Kryukov 1-Apr-11 4:16am

OK. You need to be extra carefull...

Speaking of which...

Don't forget it's 1st of April today :-) :-)
Please see this post (and of course my "Answer"): http://www.codeproject.com/Answers/175616/WARNING-Black-Line-of-Death-in-windows-phone-7.aspx

:-) Regards.

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Answer 1 · 2011-04-17T11:20:00

There is one cunning and a very robust mechanism using the idea of see seeding of the exception.
It was invented by one former Microsoft engineer and was is implemented in .NET without much buzz about it. I used to fully implement it. It uses fully documented Windows API, but the non-portable part of it — you need to modify Instruction Pointer in thread's swapped out status data.

I tried to explain how it works in my comments on this page: How do I abort a specific thread that is already running?[^]. To locate it, please find the Answer by Olivier and my comments by the key words "exception seeding".

The key API to use is GetThreadContext (http://msdn.microsoft.com/en-us/library/ms679362(v=vs.85).aspx[^]) and SetThreadContext (http://msdn.microsoft.com/en-us/library/ms680632(v=vs.85).aspx[^]). What's important, you can call it from the thread other then the one to be aborted. You suspend the thread, get its content, modify Instruction Pointer to point to your function throwing the exception (define exception class, say "ThreadAbortException") and resume the thread. When you resume the thread, stack frame will be broken, but it does not matter, because you jump to exception throwing method (will never return). The thread body should run in the try-catch block, catch ThreadAbortException and perform all post mortal clean-up there. Most importantly, release all locks, etc.

To see what can you avoid by replacing TerminateThread with this mechanism, read help on this topic: http://msdn.microsoft.com/en-us/library/ms686717(v=vs.85).aspx[^]. You can avoid all problems (and many less difficult ones) by handling ThreadAbortException.

The implementation is not very difficult at all. It replaces unsafe TerminateThread with a very gentle way to abort it, leaving a thread with a possibility to process its post-mortal action accurately. You can even avoid termination of the thread by getting it all in a loop.

The implementation is fairly simple and the code is short, the mechanism is very robust.
Please ask your questions if you're interested, I'll be able to help you, but you better try to implement it yourself.

[EDIT]

See also my recent answer:
Problem with creating Process from dedicated thread[^].

—SA