Self restarting property of RTOS-How it works?

**** top-posting fixed ****

"s.subbarayan" wrote:
> Tim Wescott <tim@wescottnospamdesign.com> wrote in message 
>> s_subbarayan@rediffmail.com wrote:
>>
>> snip
>>
>>> After restarting will the task start executing from the starting
>>> point or will execute from where it left?(that means continue
>>> executing,from the point where its terminated before restarting?).
>>>
>>> Incase it starts executing from scratch from the place where its
>>> spawned,will it not cause problems to my application?For eg,I am in
>>> middle of some biomedical application and some task goes for a toss
>>
>> snip
>>
>> Are you saying that it's acceptable in any way, shape or form for
>> a task in a biomedical application to "go for a toss"?
> 
> While I appreciate your sincerity in replying,I would be happy if
> you avoid circausism in your reply.When I say task goes for a
> toss-this does not mean that always it goes to it,I was refering
> to the exceptional condition,such exceptional conditions do happen
> in biomedical world,if you could remember or read about THERMAC
> radioactive machines which failed due to some problem.While people
> take exceptional care for biomedical,some times human error do
> happen. I believe you are also human being to accept errors and no
> ones GOD here remember.

Please do not toppost.  Your answer belongs after the material to
which you reply, after snipping whatever is not germane.

There is a language barrier here.  You are both expressing the same
concern for the medical patient.  THERAC, IIRC, was due to the
silly use of a language and system that did not catch overflows
(such as most C systems).

-- 
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson

> There is a language barrier here.  You are both expressing the same
> concern for the medical patient.  THERAC, IIRC, was due to the
> silly use of a language and system that did not catch overflows
> (such as most C systems).

While that was a contributing factor, the real problems were those of
all systems that do parallel processing in one form or the other: syn-
chronization, global time and event ordering, inconsistent system state.
There's a lot of public information available, down to the implementation
behind certain features that led to the errors. Whether that code was
written in C was largely irrelevant.

	Jan

In article <QoiOd.3768$mG6.73@newsread1.news.pas.earthlink.net>, 
horedson@earthlink.net says...
> "s.subbarayan" <s_subbarayan@rediffmail.com> wrote in message 
> news:c396173e.0502082037.54b8b7e@posting.google.com...
> > Hi,
> > While I appreciate your sincerity in replying,I would be happy if you
> > avoid circausism in your reply.When I say task goes for a toss-this
> > does not mean that always it goes to it,I was refering to the
> > exceptional condition,such exceptional conditions do happen in
> > biomedical world,if you could remember or read about THERMAC
> 
> Therac-25.
> Not a computer problem per se, but often used as
> an example of system failures due to design error.

And as much (or more) to the point of the original question no thread or 
task 'went for a toss' so restarting would have had no effect.

Robert

CBFalconer wrote:

> 
> There is a language barrier here.  You are both expressing the same
> concern for the medical patient.  THERAC, IIRC, was due to the
> silly use of a language and system that did not catch overflows
> (such as most C systems).
> 

My one value-adding experiencing with Ada was debugging code written by 
another company who's attitude was "you write in C, therefore all the 
bugs are yours".

You can write crappy code in any language.

You can write solid, quality code in any language.

I liken writing life-critical code to driving a car full of sleeping 
children: I can pretty much do anything I choose, but some of my choices 
can be quite disastrous for a number of innocent lives.  If _all_ layers 
of your organization take responsibility for the lives of the people who 
can be affected by the product, and if the people working with the 
software are aware of the known methods for developing then chances are 
the software will be up to snuff.  It doesn't really matter whether the 
language is C, Ada, assembly or COBOL (although a flight-control or 
biomedical system written in COBOL boggles the mind).

It ain't the code, it's the coders that make the difference.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Tim Wescott wrote:

>I liken writing life-critical code to driving a car full of sleeping 
>children: I can pretty much do anything I choose, but some of my choices 
>can be quite disastrous for a number of innocent lives.  If _all_ layers 
>of your organization take responsibility for the lives of the people who 
>can be affected by the product, and if the people working with the 
>software are aware of the known methods for developing then chances are 
>the software will be up to snuff.  It doesn't really matter whether the 
>language is C, Ada, assembly or COBOL (although a flight-control or 
>biomedical system written in COBOL boggles the mind).
>
>It ain't the code, it's the coders that make the difference.

I would broaden the above to include the hardware designers.
The earlier models in the Therac series had a microswitch that 
would not allow the electron beam to go to lethal levels unless
the electron-beam-to-x-ray converter was in front of the emitter.
The Therac-25 simply turned on the motor and waited X seconds.
The fact that a software bug made it fail to wait is the fault of
the coders, but the fact that the hardware-based lock wasn't there
was the fault of the system/hardware designers.

I have worked on aircraft systems where we did the following:

[1] Challenged the software engineers to write example code that 
    manages to bypass the hardware interlocks.

[2] Challenged the hardware engineers to introduce a faulty 
    component (usually a sensor) that manages to confuse or crash 
    the software. 

You can't always do the above, but with many designs you can. 


-- 
Guy Macon
<http://www.guymacon.com/>

"Tim Wescott" <tim@wescottnospamdesign.com> wrote in message 
news:110jj8fpoqmaea5@corp.supernews.com...
> Top-posting fixed.
>
> s.subbarayan wrote:
>>
>> Tim Wescott <tim@wescottnospamdesign.com> wrote in message 
>> news:<110f5dul9b2grdc@corp.supernews.com>...
>>
>>>s_subbarayan@rediffmail.com wrote:
>>>
>>>snip
>>>
>>>
>>>>After restarting will the task start executing from the starting point
>>>>or will execute from where it left?(that means continue executing,from
>>>>the point where its terminated before restarting?).
>>>>
>>>>
>>>>Incase it starts executing from scratch from the place where its
>>>>spawned,will it not cause problems to my application?For eg,I am in
>>>>middle of some biomedical application and some task goes for a toss
>>>
>>>snip
>>>
>>>
>>>Are you saying that it's acceptable in any way, shape or form for a task 
>>>in a biomedical application to "go for a toss"?
> >
> > Hi,
> > While I appreciate your sincerity in replying,I would be happy if you
> > avoid circausism in your reply.When I say task goes for a toss-this
> > does not mean that always it goes to it,I was refering to the
> > exceptional condition,such exceptional conditions do happen in
> > biomedical world,if you could remember or read about THERMAC
> > radioactive machines which failed due to some problem.While people
> > take exceptional care for biomedical,some times human error do happen.
> > I believe you are also human being to accept errors and no ones GOD
> > here remember.
> > Regards,
> > s.subbarayan
> >
> >
> The Therac 25 killed because of piss-poor design in a piss-poor 
> environment that allowed piss-poor software quality -- probably because 
> people had the attitude that mistakes happen and errors that may kill me 
> or you are acceptable as long as money is being made.  For details on the 
> Therac 25 accidents see 
> http://www.embedded.com/showArticle.jhtml?articleID=55300689 and 
> http://sunnyday.mit.edu/papers/therac.pdf.  When those tasks "went for a 
> toss" it was because several somebodies weren't paying a hell of a lot of 
> attention.
>
> The _only_ excuse that can be granted is that the Therac 25 was one of the 
> first systems where the software had the power to kill people.  It's been 
> 20 years, we should know better now.  These days going to exceptional 
> lengths to insure software quality in life-critical applications is no 
> more playing god than changing your tires when they go bald, it's simply 
> doing what should be done.


There were also serious hardware design flaws with the Therac-25.
The whole system design was a disaster, including operator training.

-- 

  ... Hank

http://home.earthlink.net/~horedson
http://home.earthlink.net/~w0rli 

Tim Wescott wrote:

>I suspect that the only times you're going to have a 
>really good part A and a really bad part B is either when you have a 
>project that doesn't have much cross-discipline awareness or if you're 
>in an organization that just doesn't care and the people doing part A 
>are personally committed to quality and have the weight or cleverness to 
>make it happen in spite of the organization.

Or, as I found out at Mattel, Part A is designed in the USA and 
part B is designed in China.

BTW, fast food eateries are starting to outsource order-taking.
When you pull up in the drive-through, you may be talking to 
someone in India.

Hank Oredson wrote:

-- snip --
>>
>>The Therac 25 killed because of piss-poor design in a piss-poor 
>>environment that allowed piss-poor software quality -- probably because 
>>people had the attitude that mistakes happen and errors that may kill me 
>>or you are acceptable as long as money is being made.  For details on the 
>>Therac 25 accidents see 
>>http://www.embedded.com/showArticle.jhtml?articleID=55300689 and 
>>http://sunnyday.mit.edu/papers/therac.pdf.  When those tasks "went for a 
>>toss" it was because several somebodies weren't paying a hell of a lot of 
>>attention.
>>
>>The _only_ excuse that can be granted is that the Therac 25 was one of the 
>>first systems where the software had the power to kill people.  It's been 
>>20 years, we should know better now.  These days going to exceptional 
>>lengths to insure software quality in life-critical applications is no 
>>more playing god than changing your tires when they go bald, it's simply 
>>doing what should be done.
> 
> 
> 
> There were also serious hardware design flaws with the Therac-25.
> The whole system design was a disaster, including operator training.
> 
True.  I've noticed that one tends to have organizations that are 
committed to quality, or organizations that aren't.  This leads to 
entire projects that are disasters from a quality standpoint, or ones 
that aren't.  I suspect that the only times you're going to have a 
really good part A and a really bad part B is either when you have a 
project that doesn't have much cross-discipline awareness or if you're 
in an organization that just doesn't care and the people doing part A 
are personally committed to quality and have the weight or cleverness to 
make it happen in spite of the organization.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

On Wed, 09 Feb 2005 19:01:00 +0000, the renowned Guy Macon
<_see.web.page_@_www.guymacon.com_> wrote:

>
>Tim Wescott wrote:
>
>>I suspect that the only times you're going to have a 
>>really good part A and a really bad part B is either when you have a 
>>project that doesn't have much cross-discipline awareness or if you're 
>>in an organization that just doesn't care and the people doing part A 
>>are personally committed to quality and have the weight or cleverness to 
>>make it happen in spite of the organization.
>
>Or, as I found out at Mattel, Part A is designed in the USA and 
>part B is designed in China.
>
>BTW, fast food eateries are starting to outsource order-taking.
>When you pull up in the drive-through, you may be talking to 
>someone in India.

I was perusing a copy of an ethnic weekly (the _Urdu Times_-- 
"North America's Largest Urdu Newspaper") over my lunch of Pakistani
halal nan and Korean bip im bap the other day, and they had companies
offering unlimited voice (over IP) to India for something like $30 a
month, retail to consumers. At less than a dime per hour for the
communication link, that could be pretty practical. 


Best regards, 
Spehro Pefhany
-- 
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

Tim Wescott wrote:
> 
... snip ...
>
> The Therac 25 killed because of piss-poor design in a piss-poor
> environment that allowed piss-poor software quality -- probably
> because people had the attitude that mistakes happen and errors
> that may kill me or you are acceptable as long as money is being
> made.  For details on the Therac 25 accidents see
>   http://www.embedded.com/showArticle.jhtml?articleID=55300689 and
>   http://sunnyday.mit.edu/papers/therac.pdf.  When those tasks
> "went for a toss" it was because several somebodies weren't paying
> a hell of a lot of attention.
> 
> The _only_ excuse that can be granted is that the Therac 25 was
> one of the first systems where the software had the power to kill
> people.  It's been 20 years, we should know better now.  These
> days going to exceptional lengths to insure software quality in
> life-critical applications is no more playing god than changing
> your tires when they go bald, it's simply doing what should be
> done.

I was building software that could kill people 10 years before
that.  I was aware of it, and it didn't.  By the late '70s my
software was almost all implemented in Pascal (real ISO standard
Pascal, with full range checking etc. - not the Borland mixture)
with everything from the naked board up under my control.  Yes,
there were failures, usually hardware, but the effect was to stop
and scream for human help.

It doesn't take a genius to recognize potential pitfalls.  People
have been building fail-safe mechanisms for centuries.

-- 
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson