Self restarting property of RTOS-How it works? - Page 5

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: Self restarting property of RTOS-How it works?
Quoted text here. Click to load it

Firstly, please separate the two.  There is nothing wrong with using
linked lists appropriately.  They should NOT be used when a necessary
primitive is to index by entry number, and you need to take care to
avoid fragmentation, but that is about all.

The latter was widepread in the 1960s in commercial systems written
in various assemblers.

Quoted text here. Click to load it

The latter is provably insoluble, though it is possible to write code
that is resistant to it.

Quoted text here. Click to load it

Computer scientists.  Students.  Employees of software houses.  etc.
Generally, they didn't test it.  And, as with the MVT Linkage Editor,
we had it 20 years after it should have been buried with a stake
through the heart of the last listing.

Quoted text here. Click to load it

They do, indeed.  But your viewpoint of what happened and who was
responsible is a bit simplistic.  It is very messy, and only SOME
of the blame should be assigned to computer scientists.  Here is a
very rough summary of one viewpoint on it:

Back around 1970, most computer scientists damned Fortran for being
unreliable (i.e. uncheckable), and supported Pascal, Lisp etc. (to
taste).  Now, they were unfair to blame Fortran, as it WAS checkable,
but had a point about the programming styles.

In parallel, A,T&T Bell Labs produced a semi-portable assembler and
computer scientists' experimental bench (C and Unix), with the full
knowledge and conscious decision that diagnostics, robustness and so
on were largely omitted both for clarity and to allow the experimenters
maximum flexibility.

In the 1970s, the first generation of people who had been trained as
computer scientists became professors etc., and regrettably many of
them took the attitude that it was someone else's business to turn
their leading-edge ideas and demonstrations into real products.  The
"someone else" was assumed to be computing service staff, vendors'
engineers etc.  Those people brought C and Unix into the mainstream.

Round about 1980, mainly in the USA and UK, the governments starting
demolishing central computing services and (in the USA) giving almost
unlimited budgets to leading-edge computer science departments for
industrial collaboration (culminating in theings like Project Athena).
The theory was that industry would behave as in the previous paragraph.

What is now called Thatcherism in the UK (though it predated here),
and can be described as dogmatic divide-and-conquer monetarism, meant
that many of the traditional links and controls (NOT just university
computing services) were emasculated or destroyed.  In subsequent
years, this affected standards organisations, government quality
control agencies and so on.  And industry often did the same with
their internal equivalents - which caused the FDIV bug, at least one
of IBM's disk fiascos, and many other failures.

Monetarism in turn gave a major boost to marketing over engineering,
which was synergistic with things like the IBM PC, leading to a wide
acceptance that it is better to have leading-edge gimmicks than
actually work.  People may forget that a single wayward program (and
EDLIN was one that could do it) would not just crash the system but
could trash the whole filing system, irrecoverably.  But that was OK.
That was the point at which I refused to move with the times, and
suffered as you might expect.

The whole of this came together, with the result that the traditional
enemy camps (Fortran, Cobol, Pascal, Lisp, compiler-generated checking
and other aspects of software engineering) got shoved into a ghetto
and deprecated as obsolete.  Most computer science work on software
engineering is on methodologies (often completely unrealistic) and
on largely irrelevant tools (i.e. they tackle needs that experienced
programmers don't have).  But EXACTLY the same is true of vendors'
products, because it is the zeitgeist that has changed.

Note that this has now reached even standards organisations, where
the misguided but traditional (i.e. precise and consistent) POSIX
was taken over by the woolly and inconsistent so-called Single Unix
Standard.  And it has reached hardware, where many vendors' now
design their firmware to reduce the visibility of failures rather
that make their products more robust.

Who comes out of this with credit?  Damn few organisations and people.


Regards,
Nick Maclaren.

Re: Self restarting property of RTOS-How it works?



del cecchi wrote:
Quoted text here. Click to load it

[snip]

Everyone else here manages to post without screwing up the ">"
characters.  Please study how the rest of us manage that and
learn how to do it in your posts.  Thanks!


Re: Self restarting property of RTOS-How it works?

Quoted text here. Click to load it
science
We will see if the defaults in Outlook Express are better than the
defaults in Thunderbird.

apparently this thread, or this part has been trimmed to only follow up
to cae.  So bye bye.
Sorry for disturbing you folks.

del



Re: Self restarting property of RTOS-How it works?

Quoted text here. Click to load it


We can only punt an answer to that if the packets are independant.  Be
the first one I've come across if they are. The trafic paterns are the
required info, plus the allowable latencies.

Neither poison nor gaussism stats do a good job in most cases, or if
they do, the load is so low you need not bother at all.


--
Paul Repacholi                               1 Crescent Rd.,
+61 (08) 9257-1001                           Kalamunda.
We've slightly trimmed the long signature. Click to see the full one.
Re: Self restarting property of RTOS-How it works?
[snip]
Quoted text here. Click to load it

That sounds more like numerical analysis than compsci.

And just what is this wonderful trade secret that compsci
people know about FP comparison that others don't?

Re: Self restarting property of RTOS-How it works?
Quoted text here. Click to load it

Compared to the quality of say the "average" ethernet controller
out there these don't seem to be all that major bloopers?

Quoted text here. Click to load it

--
    Sander

+++ Out of cheese error +++

Re: Self restarting property of RTOS-How it works?
Quoted text here. Click to load it
... snip ...
Quoted text here. Click to load it

  <http://cbfalconer.home.att.net

--
"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
We've slightly trimmed the long signature. Click to see the full one.
Re: Self restarting property of RTOS-How it works?
Quoted text here. Click to load it

Surely "restart" is self-explanatory?

Quoted text here. Click to load it

Damn. Fell for the troll :-(

*plonk*

Al.

Re: Self restarting property of RTOS-How it works?

Quoted text here. Click to load it
point
executing,from

If this is the case, your question mark is redundant.

Quoted text here. Click to load it

Whenever someone asks a newbie question there are always would be gurus
who feel obliged to be insulting even if the question was politely
expressed. I think there is a pattern here.

Quoted text here. Click to load it

Right


Re: Self restarting property of RTOS-How it works?
If you restart a task you restart it you do not set it back to working.  If it
is crashed (tossed) there is no place
to go to resume.  Only a paused task may resume.

The Question everyone is pointing to is:
1. Crashing is always a software problem.  No input should cause the code to get
lost.
2. Restarting crashed task may be a bad Idea. For the Therac example suppose the
dose task dies. If you restart it
does it try to give another dose?  What if it keeps crashing and restarting. Can
the system figure out if the
restart is helping or making it worse?

One use for restart would be (to use my battery charge as an example, though I
did no do it this way)
The battery Charge Task has found a battery and is charging it.  The removal
Task has fond the battery was
removed.  It could restart the Charge Task this would cause it to Restart to
look for a new battery.  This may or
may not work better than sending message or flag.

I respond to a crashed Task by forcing a watchdog reset.  I know that is safe
and preferred in my system.

Hope this helps.




Re: Self restarting property of RTOS-How it works?


Quoted text here. Click to load it

Only if you define "crashing" as a subset "software problem."

Your code can be perfect, but if the crystal oscillator stops
it *will* crash.



Re: Self restarting property of RTOS-How it works?
Quoted text here. Click to load it

No it won't; it just won't get anywhere.

I mean, even if the DRAM disappears because it's not getting refreshed
anymore, the software won't crash because time has stopped. It's frozen.
--
Roger Ivie
snipped-for-privacy@ridgenet.net
We've slightly trimmed the long signature. Click to see the full one.
Re: Self restarting property of RTOS-How it works?

Quoted text here. Click to load it

Like I said, only if you define "crashing" as a subset of "software
problem."  If you *by definition* say that only software problems are
crashes, then you can of course conclude that only software problems
are crashes - a tautology.  If you define crashing as a certain class
of undesirable system behaviors (as I do), then it doesn't matter
whether the described behavior is caused by an infinite loop with
interupts turned off or a bad RAM chip.




Re: Self restarting property of RTOS-How it works?
_see.web.page_@_www.guymacon.com_ says...
Quoted text here. Click to load it

Let me add another example of a HW problem leading to a crash.  Putting a
quickly re-occuring interrupt on the NMI input.  If an interrupt burst
lasts long enough it will bring the micro to a halt.  Even a short burst
can cause a large stack depth as context is save repeatedly overwriting
areas of memory used by other parts of the program causing problems later
in execution. I'd call that a crash and it's not solvable in software.  
There are a number of harware solutions of greater and lesser
acceptability.

Robert

Re: Self restarting property of RTOS-How it works?
Hi,
Thanks for your reply.My inference from your reply is that better
avoid using taskrestart when working on critical areas and use it only
on noncritical tasks.
But only one doubt reminds still to me:
I agree that its not possible to resume a task,when it crashes.But
when I restart it,How do we make sure that we are in synch with the
current status of the application,the same dosage problem as stated in
your posting?What if the task which is restarted requires a semaphore
or a message which is held by some other task at the time of
restarting?How do we make sure that the application reaches safely
with out causing any trouble to the current situation?

Regards,
s.subbarayan

Re: Self restarting property of RTOS-How it works?



Quoted text here. Click to load it

That is the problem unless you can make it work you can not use it.  There
may not be a safe way to restart a specific task.  It is your system so
you get to figure it out.  You may only be able to put the system in a
"safe" state if there is a problem.



Re: Self restarting property of RTOS-How it works?

Quoted text here. Click to load it
get lost.

Quoted text here. Click to load it

THe Therac problem was that no one considered what would happen if the
operator did an ABA type mode change with out waiting for either step
to complete. The result was the real world was out of step with the
software internal state. This negated the effect of the saftey checks.

Although no input SHOULD cause a fault, and all Florida swampland
should be wonderfull, in real systems there are some things where you
need to act ASAP to prevent interesting times. Railway switching,
BOS converter injection, plating power supplys to think of a quick few.

It is not the system that figures out if a task is restarted or not, that
is for the designer. The system just has to implement it.

--
Paul Repacholi                               1 Crescent Rd.,
+61 (08) 9257-1001                           Kalamunda.
We've slightly trimmed the long signature. Click to see the full one.
Re: Self restarting property of RTOS-How it works?


Quoted text here. Click to load it

Actually, they did consider it and concluded that it was impossible
- and they were (sort of) right.  The Therac had separate well-tested
code that ran the machine, and separate not-so-well-tested code that
ran the operator interface.  As originally shipped, it was impossible
to complete the data input that fast.  Then they started getting
complaints about having to re-enter the data in a bunch of fields
every time, so they put in a feature where a tab would give you the
same input as was used in the last run.  Because it was in the
operator interface code, it didn't get tested as well.  What testing
they did do failed to show the bug because developers tend to watch
the screen looking for odd behavior, while an actual operator hits
the tab key as fast as he/she can in order to do the next run.

I still think that the biggest error was taking out the microswitch
with hardware that wouldn't let it operate if the mechanical moving
parts had not arrived where they should be.  Just sending the move
command and waiting N seconds was an unacceptable system design
decision whether or not the code was buggy.  The cryptic error
messages and the ability to keep trying to dose the same patient
over and over in response to an error message didn't help things.

I have worked on systems for aircraft where the software engineer
was invited to write malicious code that would damage the hardware,
with a reward of an extra week of vacation time for writing that code.
Then the hardware engineer was invited to induce a single fault that
would cause the real software to lock up, go crazy, etc, with the
same reward offer.



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


Re: Self restarting property of RTOS-How it works?



Quoted text here. Click to load it
get lost.
Quoted text here. Click to load it

I agree the code must be good enough that it does not runaway, crash, or become
confuse due
to bad input.
It should stop or recover.

Unlike my car.  An engine temperature sensor opened.  the computer decided it
was very
cold.  It leaned the mixture till the head gasket blew.  It should have notice
the engine
never got any warmer.  Unexpected states should always lead to safe behavior
and/or blinking
lights and buzzers.



Re: Self restarting property of RTOS-How it works?

Quoted text here. Click to load it

===SNIP===

Quoted text here. Click to load it

===SNIP===

Quoted text here. Click to load it

From the starting point.

Quoted text here. Click to load it

That is for you to determine.  I have no idea how it would affect
*your* application.  I only know how it would affect *mine*.

Quoted text here. Click to load it

So it sounds like you've answered your question -- taskRestart() "may
not be suitable...".

--
Dan Henry

Site Timeline