"The creation of the RTP is separate from the loading of the
application. The creation phase of an RTP is a minimal activity to
verify that the application is a good ELF image, create the objects
associated with the RTP, create the initial memory context, and create
the initial task running within the RTP. This first stage runs in the
caller's context. The second phase (loading and instantiating the RTP)
executes in the newly created task, within the new process's memory
context, and runs at a priority specified by the user. The RTP pays
the cost of loading itself; the original caller does not incur any
cost for loading the RTP. The original caller can wait for the RTP to
be fully loaded, however, if this is required for synchronization
purposes."

I found this in a whitepapaer from Wind River and things gut more
clear now, but I still need something explained.

The initial task created in a new process will load entire executable.
Will there be two tasks in the new process, the initial task and the
actual application task or will the initial task end when finished
loading or will the loaded executable be a part of the initial task?

On Apr 6, 1:18*pm, mrkozmic wrote:
> I have read most of what is written about processes and tasks here,
> but I get more and more confussed.
>
> Could someone please give a graphical overview of processes and tasks
> and their creation?
>
> In VxWorks Application programmer's guide it is written that processes
> are not scheduled, but they can be preempted. What does that mean?
>
> Can a task created by another task access the first tasl's global
> variables?
>
> many thanks
> michal

Hi Michal,
A task is a seperate "thread of execution". In a normal C program,
imagine that you have few functions ( i.e. main has function1(args),
function2(args), etc. Now, if & when they are called, they inherit a
context ( such as local parameters, arguments, etc), execute in the
order they are called, and , perform some useful things and then, they
exit often times returning some value.

But, in a real time OS, (thoeritically) each of them "can be" run as a
seperate, independant "thread of execution",
This operation is called "spawning a seperate task" in vxworks
notation.
These seperate threads take few paramenters, among other thigs, a
priority, a scheduling type, and other parameters.

If you are familiar with pthread types of threads, you would
understand that it is some thing similar.
The scheduler ( which is called kernel) would schedule these
"independant tasks" based on its "scheduler policy".
So, from a programming point, the CPU actually executes "only one
task" at any "absolute point of time. But, from an observation point
of, it gives an impression that the OS is multi-tasking.

Because of the pre-emption nature of these tasks, its is difficult to
predict "what task can run" during the "next scheduler time slice".
( although you can find out what is currently running, but its
difficult to predict which of the ready tasks can be run during the
"forthcoming scheduler time slice". These tasks are selected from
"kernel's ready Q". The readyQ contain "all the RUNNABLE TASKs that
can run during futher time slices. This readyQ will be dynamicallly
changing all the time.
Hope this clarifies little bit of "multiple independant tasks".
-Venkat Dyavana

On Apr 6, 12:06 pm, mrkozmic wrote:
> "The creation of the RTP is separate from the loading of the
> application. The creation phase of an RTP is a minimal activity to
> verify that the application is a good ELF image, create the objects
> associated with the RTP, create the initial memory context, and create
> the initial task running within the RTP. This first stage runs in the
> caller's context. The second phase (loading and instantiating the RTP)
> executes in the newly created task, within the new process's memory
> context, and runs at a priority specified by the user. The RTP pays
> the cost of loading itself; the original caller does not incur any
> cost for loading the RTP. The original caller can wait for the RTP to
> be fully loaded, however, if this is required for synchronization
> purposes."
>
> I found this in a whitepapaer from Wind River and things gut more
> clear now, but I still need something explained.
>
> The initial task created in a new process will load entire executable.
> Will there be two tasks in the new process, the initial task and the
> actual application task or will the initial task end when finished
> loading or will the loaded executable be a part of the initial task?

No, the initial task, becomes the application task of the process.

The best way to think about RTPs is like a Linux or Windows
executable. When you run an executable there's an initial task -
that's the task that runs main(). Most executables only have a
single, initial task.

In VxWorks, the task that's created to load the RTP morphs into
the initial task within the newly loaded process, and its the one
that starts executing main()

RTPs were designed to work very much like a Linux process
(POSIX to be strict), albeit with some important differences
because of the need to be able to support real time requirements

In essence, an RTP is a collection of tasks/threads which share
the same memory context, and run code from the same executable;
there is always at least one task within a process.

The primary difference is that the scheduling of the tasks within
the process is managed globally for all tasks in the system,
which maintains the real time characteristic of the OS.

This allows you to develop applications as executables,
gives memory protection at the executable/RTP level,
provides resource reclamation when an RTP exits, but
still maintains global scheduling and worst case latency
guarantees.

Cheers!

Jason