From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.13.248.4 with SMTP id i4mr10569884ywf.20.1465358774255; Tue, 07 Jun 2016 21:06:14 -0700 (PDT) X-Received: by 10.157.11.135 with SMTP id 7mr324837oth.17.1465358774190; Tue, 07 Jun 2016 21:06:14 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!peer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!q32no5061108qgq.0!news-out.google.com!z5ni179qge.0!nntp.google.com!p34no4041343qgp.1!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 7 Jun 2016 21:06:13 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=2601:191:8202:8510:5985:2c17:9409:aa9c; posting-account=fdRd8woAAADTIlxCu9FgvDrUK4wPzvy3 NNTP-Posting-Host: 2601:191:8202:8510:5985:2c17:9409:aa9c References: <25c43463-47ca-4021-82ee-299e6a075faa@googlegroups.com> <2c0dfaf8-9344-4b9c-87b4-12de687687ce@googlegroups.com> <0dc88dae-098b-4282-b1da-4798cc14131d@googlegroups.com> <8ada2408-b58b-4a32-bc95-f90689d5a8e4@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <79b3d527-cc80-44ae-b9d2-1a4d3e9affb7@googlegroups.com> Subject: Re: Advice, tasking and hardware From: rieachus@comcast.net Injection-Date: Wed, 08 Jun 2016 04:06:14 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 3623 X-Received-Body-CRC: 540369685 Xref: news.eternal-september.org comp.lang.ada:30655 Date: 2016-06-07T21:06:13-07:00 List-Id: On Tuesday, June 7, 2016 at 4:21:15 PM UTC-4, Dmitry A. Kazakov wrote: > On 2016-06-07 18:53, rieachus@comcast.net wrote: > > 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 no= t > >> 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. >=20 > Why do you think aborting task would heal that? Why not zeroing a random= =20 > section of memory, sending an SMS, or assigning 666 to the process counte= r? >=20 > > If the deadman timer runs out, > > there is a serious problem and the airplane (or launch vehicle) is > > falling out of the sky. >=20 > Yes, but that is not to address by some random actions. You have to=20 > bring the system to the nearest known safe state. Restarting a task=20 > might be one, unless the cosmic ray hit the task body's code, external=20 > objects the task uses, other tasks and hardware it communicates to etc. Code is in Flash, with caches that get flushed on a restart. the software c= onsists of a number of tasks all dispatched by a 50 Hz (or some such) clock= . In other words, the tasking (source) code is a few dozen lines, and the = select statement is about the only tasking operation used in the operating = code, absent extreme events. It is fairly common for flipped bits to result in a task which is in an ind= efinite loop, and no lower priority tasks get to run. The code example I g= ave tries stopping and restarting every task, and any that don't stop get a= borted and then restarted. May not be perfect, but about the best you can = do with cosmic rays around. (The operating tasks where possible detect a re= start and don't depend on any data they own in DRAM memory.)