1. Home
  2. Embedded Programming
  3. Self restarting property of RTOS-How it works?

Self restarting property of RTOS-How it works?

Dear all, I was going through the explaination for taskRestart() call in the vxworks reference manual.I believe such a feature is available for most of the RTOS in the market.This dicussion talks about vxworks,But it applies in general for any rtos which offers a restarting facility.I am looking for replys from a architecture perspective rather then os specific discussion.

Vxworks reference manual for taskRestart() states the following: "This routine "restarts" a task. The task is first terminated, and then reinitialized with the same ID, priority, options, original entry point, stack size, and parameters it had when it was terminated. Self-restarting of a calling task is performed by the exception task. The shell utilizes this routine to restart itself when aborted. "

I have never got a chance to use this call in my application,but curious to learn how it works.Heres my doubt:

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 and I restart it using this call,the task will start performing everything from scratch which may not be suitable to the current status of application(In terms of micro heart surgery,typically lets say the task performing the cutting of tissues goes for a toss after some time,and I restart,if it again starts cutting the tissues which is not required for me,because I have already removed it!).

If its otherway around,for eg it starts executing from the point where it got terminated,how does the task ensure it gets all the resources like I/O device,semaphores or some other resource,which is required to execute from the point where it was terminated?Because the time before it restarts,may be there can be another high priority task which may own the resources required by the current task and I feel this should not be possible because it will cause problem to the entire application.

In precise can someone clarify me how this taskRestart() call work?Under what situations its preferred to use this call?What are the pros and cons of using this call in our application?

Looking farward for your replys and advanced thanks for the same,

Regards, s.subbarayan

Reply to
s_subbarayan
Loading thread data ...

You wil find an explanation and advices here:

formatting link
Look for restarting a task

Reply to
Lanarcam

snip

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"?

--

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

Surely "restart" is self-explanatory?

Damn. Fell for the troll :-(

*plonk*

Al.

Reply to
Al

point

executing,from

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

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.

Right

Reply to
Lanarcam

Oh, is that not acceptable? I hadn't fully divined your attitude toward the patients...

Rufus

Reply to
Rufus V. Smith

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

Reply to
R Adsett

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
Reply to
Hank Oredson

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.

Reply to
Guy Macon

-- snip --

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
Reply to
Tim Wescott

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
Reply to
Spehro Pefhany

... snip ...

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
Reply to
CBFalconer

It was nearly 1:00AM, and I left out the "in the medical industry". Just out of curiosity what industry were you working in?

I have noticed that there is a strong tendency for people to view the software engineering process as somehow fundamentally different from mechanical, electrical or other "old-line" engineering processes -- so where there will be significant controls and reviews on mechanical and electrical assemblies, a software engineer may be allowed to compile something, test it for two minutes, and ship product.

--

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

I attended a lecture by Jack Ganssle on ESC last September in which he talked about a software engineer whose software error rate was way lower than their co-workers'. The guy was formerly a hardware engineer. When asked about it, the guy said nobody told him he was allowed to err. The pervasive "bugs are unavoidable" attitude of software engineering professionals has perhaps established a tolerance for errors much higher than it would be acceptable. The fact "it's just software, please add this and this last minute feature and fix" doesn't help at all.

Just my EU0.02

Elder.

Reply to
Elder Costa

... snip ...

-- "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

Reply to
CBFalconer

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.

Reply to
Neil Kurzman

the

so

and

lower

The

higher

Like hardware doesn't have bugs or "errata". Go check Intel's web site.

Especially new hardware. sheesh

Reply to
del cecchi

===SNIP===

===SNIP===

From the starting point.

That is for you to determine. I have no idea how it would affect

*your* application. I only know how it would affect *mine*.

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

-- Dan Henry

Reply to
Dan Henry

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

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

Reply to
Guy Macon

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
rivie@ridgenet.net
http://anachronda.webhop.org/
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/P d- s:+++ a+ C++ UB--(++++) !P L- !E W++ N++ o-- K w O- M+ V+++ PS+
PE++ Y+ PGP t+ 5+ X-- R tv++ b++ DI+++ D+ G e++ h--- r+++ z+++ 
------END GEEK CODE BLOCK------
Reply to
Roger Ivie

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.