Process vs Task model benefits for RTOS-mainly vxworks!-Let me understand this plz!

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

Translate This Thread From English to

Threaded View
Gurus,
Till vxworks5.5,windriver guys have been using task based model in flat
address mode for application scheduling,but now with vxworks 6.0
windriver is playing with idea of using process model over tasks.
My question is what could be rational behind this?AFAIK,there were not
much of problems with task models and only advantage of going for
process model is enabling memory protection.But the adverse effect of
this would be timing impact due to MMU calculations every time context
switch happens and Windriver accepts there is performance hit in terms
of timing but still its deterministic.I am not able to understand how
this would be deterministic?And how far we can benefit from memory
protected applications?Because prior versions of vxworks were able to
achieve good performance even with out memory protection.

Guys using Linux whats your opinion on this?

Can some one explain me this?

Regards,
s.subbarayan


Re: Process vs Task model benefits for RTOS-mainly vxworks!-Let me understand this plz!
Hello,

There were some great white papers written up to explain Wind Rivers
memory and process model in 6.0.

http://www.windriver.com/portal/server.pt/gateway/PTARGS_0_39823_381175_0_0_18/rtps_for_vxworks6_wp.pdf

http://www.windriver.com/portal/server.pt/gateway/PTARGS_0_39823_381177_0_0_18/vxworks_memory_allocation_wp.pdf

Your local Account Team can also provide you with benchmarks regarding
the MMU overhead w.r.t. context switching.  Realize that the kernel is
always mapped into your local context so it's not like you have to load
all the TLB entries when moving between RTPs...only the user level
pages have to be loaded/unloaded; the overhead I've see is minimal on
all PPC architecture especially when compared to the savings in
development / maintenance when problems occur.

Jamie

ssubbarayan wrote:
Quoted text here. Click to load it


Re: Process vs Task model benefits for RTOS-mainly vxworks!-Let me understand this plz!
Try the following short cuts, if they don't work than search off the
main www.windriver.com page for "mem white paper" and "rtp white paper"

http://www.windriver.com/portal/server.pt?space=Opener&control=OpenObject&cached=true&parentname=SearchResult&parentid=4&in_hi_ClassID18%&in_hi_userid27%106&in_hi_ObjectID38%1175&in_hi_OpenerMode=2 &

http://www.windriver.com/portal/server.pt?space=Opener&control=OpenObject&cached=true&parentname=SearchResult&parentid=3&in_hi_ClassID18%&in_hi_userid27%106&in_hi_ObjectID38%1175&in_hi_OpenerMode=2 &


Re: Process vs Task model benefits for RTOS-mainly vxworks!-Let me understand this plz!

Quoted text here. Click to load it

Those are both the same link.  But they do work for one of the papers
(not the other one.)  Thanks.

Jon

Re: Process vs Task model benefits for RTOS-mainly vxworks!-Let me understand this plz!

Quoted text here. Click to load it

I get:

   Error - The server has experienced an error. Try again, or contact
   your Portal administrator if you continue experiencing problems.

Problem?

Jon

Re: Process vs Task model benefits for RTOS-mainly vxworks!-Let me understand this plz!

Quoted text here. Click to load it
<snip>

You might be able to achieve an effect similar to 5.5
by running all your threads in _one_ process. After all,
5.5 is just one big anonymous process that contains
all those 5.5 threads.


Re: Process vs Task model benefits for RTOS-mainly vxworks!-Let me understand this plz!
Quoted text here. Click to load it

In my humble opinion, and still after reading the white papers, it is
just a means for lazy or incapable programmers, which adds overhead.
You can develop your code with the MMU on and after some testing and
verifying, that there is no memory violation (program error) you can
switch the MMU off and after the final testing ship your product without
the unnecessary overhead.
I wish I could do the same thing with Linux:)

Regards,
Robert

---
Robert Berger
Embedded Systems Software Group Leader

We've slightly trimmed the long signature. Click to see the full one.

Site Timeline