1. Home
  2. Embedded Programming
  3. Process vs Task model benefits for RTOS-mainly vxworks!-Let me understand this plz!

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

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

Reply to
ssubbarayan
Loading thread data ...

Hello,

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

formatting link

formatting link

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:

Reply to
Jamie

Try the following short cuts, if they don't work than search off the main

formatting link
page for "mem white paper" and "rtp white paper"

formatting link

formatting link

Reply to
Jamie

I get:

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

Problem?

Jon

Reply to
Jonathan Kirwan

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

Jon

Reply to
Jonathan Kirwan

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.
Reply to
dolissimus

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

INTRACOM S.A.
Hellenic Telecommunications & Electronics Industry
Content Delivery Systems Department
P.O. Box 68, 19.5 km Markopoulo Ave. (Building A)
190 02 Peania, Athens, GREECE
Tel.: (+30 210) 667 4353, 667 9000
Fax.:(+30 210) 667 7101
email: rber@intracom.gr
URL: www.intracom.gr
Reply to
rber

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.