Re: Advice, tasking and hardware

[Dennis Lee Bieber <wlfraed@ix.netcom.com>]

On Tue, 7 Jun 2016 09:53:37 -0700 (PDT), rieachus@comcast.net declaimed the
following:

>On Monday, June 6, 2016 at 3:19:20 AM UTC-4, Dmitry A. Kazakov wrote:
> 
>> As questionable aborting task is, if do, that is unrelated to any 
>> protected objects. They block nothing unless erroneous, e.g. when you 
>> run an infinite loop within a protected action. If you do you would not 
>> be able to abort the task stuck in the action, it is abort-deferred.
> 
>Sigh!  This is the one instance where aborting a task is not just appropriate, but sometimes necessary.  I have no control over, for example, bit flipping by cosmic rays.  If the deadman timer runs out, there is a serious problem and the airplane (or launch vehicle) is falling out of the sky.  For tasks which close as expected, my code does not abort them.  For tasks that keep running, abort may clear the issue.  If it doesn't?  You have a very expensive pile of wreckage to analyze.  If a task got stuck in a loop but not in an abort deferred area, the abort works, and if the times are set right, you may recover the system.

	Based on the systems I've seen at my current employer... If, for
example, a deadman timer does go off... The entire system is restarted --
recreating ALL tasks -- but attempting to save the data state (a cold start
does destructive RAM tests, a warm start skips those).

	No attempt is made to abort pieces of the system or restart them. All
tasks are created during the initialization phase, before the system is
"active".
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/