Re: How to rollback another stack in C++?
chengpu@gmail.com wrote:
I am writing an interface base class <IThread>, and I do not have the
control of the implementation of the derived class. Your descriptions
fits into the infinitive loop: the derived <IThread>::ProcMsg() never
returns.
Write a template method in your base class that dictates the processing
of all messages. Write an abstract interface to a Mailbox/MsgQ that
provides allows you to get the next message. The implementation of the
queue is typically blocking until the next message arrives. The
processing of the messages happen in an all catch loop.
// Called from derived task entry point. Remains in here till
terminated.
int ThreadBase::processMessages()
{
//Binary Sem, task remains dormant until signalled
activateSem_.acquire( WAIT_FOREVER );
while( !terminated_ )
{
try
{
//Blocks until next arrives - The WaitForMultipleObjects call
lives in here!
boost::scoped_ptr<Msg> next( threadQ->get() );
next->process();
next.reset( 0 );
}
catch( const std::exception& ex){ /*handle*/ }
catch( ... ){ /* terminate() or handle*/ }
}
}
The message itself can be intelligent enough to decide whether it is
still applicable or not. For some derivitives of message it will always
be applicable, and the check is never performed. For others they
perform the check. The task is terminated from a God context by simply
calling terminate. Binary semaphores can typically also be used...
while( !terminateSem_.acquire( NO_WAIT ) )
{
...
}
I personally use something similar to a rendezvous, that blocks the
terminating task until the terminated task has truly exited (I signal
the rendezvous just before the closing brace). Basically the rendezvous
is implemented as a mutex, whereafter waiting on a binarySem. The
recipient signals the binary sem on completion. All task always
terminate normally - not by calling the OS terminate, but normally -
therefore the stack always unwinds. I don't bother with trying to catch
forever loops at a higher level, for the same reasons Le Chaud
mentioned - its their problem. One could have a supervisor that
monitors the tasks - we have one mainly for diagnostic purposes.
Typically tasks can suspend, but usually that is due to some serious
problem - respawning does not remove the more serious problem.
The normal implementation (Win32 and UNIX) of "terminates and respawns
it" has two
problems:
1) It never reclaim the stack, instead, it just abandons it, probably
creating a stack leak (but you never see this because you have a lot of
memory.
Can't really comment on the stack leak. I would have imagined the OS
handles this for you. In general we never terminate hard.
2) the state of the object is in limbo;
Not true if delete from another context. Objects (representing the
task) and the context itself are orthogonal. If you terminate, nothing
prevents you from deleting the object. I'm also not sure what you mean
by the stack leaking - is it not unwound? I would have to test that to
be sure. Therefore, what you are saying is local destructors aren't
called? Typically this is due to programming error, though. You might
as well terminated everything - or if you must, recover what you can
and ignore the slight leak.
You mean for the <IThead>::ProcMsg() to poll isApplicable() between
each instruction?
Well, the isApplicable() can be handled by a more specific message in
the actual processing of the message, instead of in Task::process().
How about calling into other functions? I do not
think that this solution is elgant enough.
Anyway, the analog here is how to cancel a transaction.
Easy, if the transaction is not applicable anymore, don't do it. If a
transaction is always applicable, it does not ask the question.
In an embedded system, I can access the context switch handler, and I
can insert a generic exception pointer into my thread object. During
context switch, if the pointer is not 0, I can throw it when the
thread/stack becomes current.
What if the code is in a tight loop over which you have no control...?
Does it still work?
.... Which gives me an idea. How about creating a terminate message,
which throws a specific exception. On catching that exception, you exit
normally. The only problem is that if the part that services the queue
is never reached (due to tight loop), checkmate.
Right now I do not think my rollback is possible in Win32 or UNIX, even
it is modest and reasonable. Because C++ or even OS does not provide
the rollback ability of a thread stack from outside, Java engine and
database engine essentially redo most OS calls to have this property.
Still not sure what you mean by Rollback. If client code sits in a
tight loop, you are doomed (IMHO). If someone knows of a way to break
the client code out of that loop, I would like to know for interest
sake - the point is - sometimes client code must be able to sit in a
tight loop. From a lower level you don't know this, except if it
becomes an attribute of your task, in which case it can only be
monitored from externally. Now you need a way to break that loop - you
can only use what the OS API provides, which is TerminateThread (for
Win32) - not nice - because your stack is not unwound, but the only
way.
Either you exit gracefully, or you terminate. In general I've never
found the reason to terminate. My exit code (WIN32 - OT, I suppose),
looks like this:
//...
::GetExitCodeThread( handle, &exitCode );
if( exitCode == STILL_ACTIVE)
{
::CloseHandle( handle );
::TerminateThread( handle, -1 );
}
else
{
::CloseHandle( handle );
}
//...
terminate is usually called after the gracefull exit, which is ensured
by the rendezvous.
Werner
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]