vxworks

[Ether]

See attached GIF file, written by Jim Collier in March 2004.

It's a bit dated, but a very succinct summary.

I am wondering if it is still correct, having been written 6 years ago.

Can anyone with vxworks knowledge comment?


~

[EricVanWyk]

I'm pretty good at admitting my weaknesses, so I'll bite first: What?



I don't really understand what the implication of the .gif is. Are you asking whether or not VxWorks supports threads? Are you asking if tasks and threads are interchangeable / good enough to be interchangeable?

[Ether]

I don't really understand what the implication of the .gif is.


The GIF is a screenshot of a web page written 6 years ago by a Jim Collier, purporting to give a top-level overview of vxworks.

http://www.cross-comp.com/instr/pages/embedded/VxWorksTutorial.aspx

Are you asking whether or not VxWorks supports threads? Are you asking if tasks and threads are interchangeable / good enough to be interchangeable?


Not specifically, no.

I was asking if the overview summary of vxworks written by Jim Collier is still correct, six years after he wrote it. Or perhaps it wasn't correct in March of 2004 when it was written.

~

[wireties]

It is close, but not entirely correct in 2004 or now. There are 5 states:

pending - blocked forever waiting on a system resource
delayed - blocked for a number of system ticks
pending & delayed - blocked for a maximum number of system ticks waiting on a system resource
ready - ready to run
running - of all the ready tasks, the one picked by the scheduling algorithm to run - note that vxworks schedules tasks (w/o regard to which RTP or the kernel where the task resides), not processes

in addition there is a suspended shadow state correlating to the pening/delayed/pending&delayed/ready states - in other words vxworks keeps track of what state a pending task would be in if you resumed it

the version of vxworks we run supports threads (called tasks in vxworks) and processes (called real-time processes) - the FIRST examples run entirely in multiple tasks inside the kernel, they do not use RTPs and I'm not sure they are enabled - so all the FIRST code runs inside the same memory context (thus the code we run can whack other tasks and the kernel itself so be careful!)

Hope this helps

[Ether]

Hope this helps


Thanks for posting. As time permits, I'm going to ponder what you have written and try to square it with other input I have received elsewhere.


~

[Ken Streeter]

the version of vxworks we run supports threads (called tasks in vxworks) and processes (called real-time processes) - the FIRST examples run entirely in multiple tasks inside the kernel, they do not use RTPs and I'm not sure they are enabled - so all the FIRST code runs inside the same memory context (thus the code we run can whack other tasks and the kernel itself so be careful!)
Your speculation that RTPs are not enabled in the vxWorks kernel running on the cRIO is correct. The vxWorks running on the cRIO requires all tasks to be run as "kernel tasks" sharing the same memory space (and thus without the resultant protections from one another.)

[gvarndell]

It's a bit dated...
Can anyone with vxworks knowledge comment?

The diagram you posted is almost identical to the diagram one would find in the "vxWorks Kernel Programmer's Guide" -- if one looked at it. :rolleyes:

You can view this document as web pages by bringing up 'Help' in Workbench.
You can also view it as a pdf, which you should find approximately here.

C:\WindRiver\docs\extensions\eclipse\plugins\com.w indriver.ide.doc.vxworks\vxworks_kernel_programmer s_guide_6.* <- '*' would be '3' for you.

[gvarndell]

It is close, but not entirely correct in 2004 or now. There are 5 states:

pending - blocked forever waiting on a system resource
delayed - blocked for a number of system ticks

etc., etc.


See the section entitled "Tasks and Multitasking" in...

C:\WindRiver\docs\extensions\eclipse\plugins\com.w indriver.ide.doc.vxworks\vxworks_kernel_programmer s_guide_6.3

Not that your paraphrasing of the information there is wrong, there's just more there.

Also note that tasks are ready, pended, running, or suspended.
The other states have more to do with why a task is pended or suspended.

[wireties]

I reckon it does not matter but I am pretty sure I am correct about the task states, It certainly does not matter to students programming FIRST robots. I taught engineers how to use VxWorks for 15+ years and the info I passed on is directly from the Wind River training presentations. The diagram from the 6.X users manual is a dumbed-down version.

If you think about it the distinction between pending, pending and delayed and just delayed is important. Making the kernel check every pending and every delayed task can be done in a deterministic manner no matter how many tasks are present in the system. Tasks that are both pending and waiting are sorted in 2 different ways (by relative time and priority or fifo) and complicate the algorithm, thus they are treated as a special case (or state) in the kernel.

Hope this helps