Re: problem delete class object contained thread
Thomas Richter wrote:
morz <blackrosezy@gmail.com> wrote:
classA
{
public:
thirdPartyThreadLibrary myThread;
void Run()
{
myThread.exec(); // created new thread and run on background.
}
};
void myGUIFunctionNamed_Execute()
{
classA * objectA = new classA();
objectA->Run();
delete objectA <---- here is my big problem.If i put this
line,
surely
myThread in classA deleted.auto_ptr
also cannot help.If i dont put this line,
my code is perfectly run,but of course
memory leaked.
So, ask yourself how long you would need the resource objectA.
I suppose as long as the created thread runs. If so, I would
dispose the object after having "joined" the thread, i.e. as
soon as the thread dies. (That is, if "join" is available and
part of your design. C++ doesn't specify what threads are, but
the most popular thread abstraction is possibly POSIX, and
POSIX does offer "join").
This depends a lot on the "thirdPartyThreadLibrary". Generally
speaking, however, he has a classical problem: if you detach a
thread, how do you destruct the thread object. Boost solves the
problem by inversing control: if you destruct the thread object,
the thread is detached (but continues to run). While this
implicit detach (and the resulting unintentional detach because
of an exception) is definitly not a feature you want to emulate,
looking at how Boost solves the problem of running a thread
after the thread object has been destructed is educational. The
key to understanding it is, of course, the realization that a
thread isn't data (at least to the user), but a function.
Conceptually, the thread can continue running after the thread
object has been destructed, provided any necessary data has been
copied locally into the function. (Of course, having the data
copied locally, rather than using the data directly in the
thread object, makes communicating back to the invoking thread
more difficult if you do want to join and get the results. But
nothing that an additional level of indirection cannot solve.)
Of course, his thirdPartyThreadLibrary may not give him this
sort of choice. But it should have some documented way of
running a detached thread, and that's what he will have to do.
And either it allows the destruction of a detached thread object
(which it doesn't need any more), or it provides some sort of
reaper to recover it. (Under Posix, pthread_cleanup_push in the
extern "C" starter function is often used to implement this.) In
the first case (e.g. boost), it is important that he not count
on any information in the thread object in his worker thread.
In the second case, probably the most frequent, you generally
have to allocate the thread object dynamically (since otherwise,
the delete done in clean-up is likely to have undesirable side
effects); typically, once you've detached the thread, it's no
longer your problem, provided there are no bugs in the
implementation. (There are subtle issues here; if detach is
called after the thread has started, the thread may have already
finished, and passed the point where it would have done the
delete. A correct implementation has to be able to handle
this.)
Finally, I'd say that if he has the choice, he should switch to
Boost::threads as his third party library. It's far from
perfect, but it seems at least as good as anything else, and
there are a lot more real experts working on improving it that
there are for anything else.
--
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]