5 Multitask PDF

Chapter
5
Real-Time Multitasking
Tornado Training Workshop
Copyright Wind River Systems Wind River Systems
5-1
Introduction
Task Basics
Task Control
Error Status
System Tasks
5.1 Introduction Task Basics Task Control Error Status System Tasks
5-2
What is real-time?
Advantages of multitasking
Tasks and task states
What is Real-Time?
Real-time denotes the ability of a control system to keep up with the system being controlled. A system is described as being deterministic if its response time is predictable. The lag time between the occurrence of an event and the response to that event is called latency. Deterministic response is the key to real-time performance.
5-3
Requirements of a Real-time System

Ability to control many external components:
q q
Independent components Asynchronous components Synchronous components Fast response Low overhead A late answer is a wrong answer.
High speed execution:

q q
Deterministic operation:
q
5-4
Design Options
knuckle1 knuckle2 wrist
elbow
shoulder
5-5
How do we design a system to control a robot arm?
Unitasking Approach
One task controlling all the components in a loop.
arm () { for (;;) { if (shoulder needs moving) moveShoulder(); if (elbow needs moving) moveElbow(); if (wrist needs moving) moveWrist(); . . . } }
5-6
Disadvantages of unitasking approach:

q q
Difcult to control the components at different rates Difcult to assign components priorities No preemption capability No context switch overhead.
Advantage:
q
Multitasking Approach
Create a separate task to manipulate each joint:
joint () { for (;;) { waitForMove();/* Until joint needs moving */ moveJoint(); } }
Each task alternates between ready and waiting. VxWorks allows a task to wait for:
q q
A specied time delay An event (e.g. an interrupt)
5-7
Multitasking advantages:
q
Using different wait commands for each task permits manipulating the components at different rates. Using a priority-based scheduler permits running the most important task in the event that two tasks are in the ready state at the same time. Using a preemptive scheduler permits an important task which enters the ready state to start running right away (preempting the less important task previously running). Permits easier addition of new components.
Task States
SUSPENDED PENDED & SUSPENDED
READY / EXEC PENDED
DELAYED & SUSPENDED
PENDED & DELAYED & SUSP.
DELAYED PENDED & DELAYED

Tornado Training Workshop Copyright Wind River Systems Wind River Systems
5-8
Non-suspended tasks may be in one of four states: Ready Tasks eligible to execute. The actually executing task has highest priority among all ready tasks. The other tasks in the ready queue are waiting for the CPU. Tasks waiting for an amount of time to pass.
Delayed Pended
Tasks waiting for an object event (e.g., a shared resource becoming available). Pended & Delayed Tasks waiting for a object event, but with a timeout specied.
Tasks may, additionally, be suspended:

q q
Suspended tasks will not execute. Tasks that are delayed or pended can be suspended. When resumed they will return to the appropriate state.
Multitasking Kernel
The Wind kernel is that part of VxWorks which directly manages tasks. Allocates the CPU to tasks according to the VxWorks scheduling algorithm (to be discussed). Uses Task Control Blocks (TCBs) to keep track of tasks.
q q
One per task Declared as WIND_TCB data structure in taskLib.h O.S. control information e.g. state, task priority, delay timer, breakpoint list, error status, I/O redirections, etc. CPU Context Information e.g. PC, SP, CPU registers, FPU registers
5-9
The TCB actually contains a pointer to the oating point register set storage location for those tasks which use oating point.
There are a few spare elds at the end of the TCB which may be used by an application to store additional information specic to a task. See the declaration in taskLib.h. The function taskTcb() may be used to obtain a pointer to a tasks TCB.
Kernel Operation
Pend TCB TCB TCB TCB Delay
sem2
msgQ0
sem1
Suspended TCB TCB TCB
KERNEL
Ready TCB TCB Executing CPU
5-10
Kernel manages the tasks, moving them from state to state based on kernel operations invoked.
A separate pend queue exists for each event. For example, an event could be a particular semaphores being given, or a message arriving across a particular message queue.
A task in the PENDED + DELAYED state is linked into both a pend queue and the delay queue. The link nodes are part of the TCB.
The ready queue is not a simple linked list. It is a bit-mapped priority queue, so that insertion and deletion are done in constant time.
Whenever any of the above queues is manipulated, kernel state is entered. Upon exiting kernel state, code executes to check whether a reschedule (context switch) should occur.
Context Switch
When one task stops executing and a new task starts, a context switch or reschedule has occurred. To schedule a new task to run, the kernel must: TCB(Old) copy of pc copy of sp ... 1. CPU pc sp ... 2. TCB(New) copy of pc copy of sp ...
1. Save context of currently executing task into its TCB. 2. Restore context of next task to execute from its TCB. Complete context switch must be very fast.
5-11
Types of Context Switches

Synchronous context switches occur because the executing task
q q
pends, delays, or suspends itself. makes a higher priority task ready to run. (less frequently) lowers its own priority, or exits. makes a higher priority task ready to run. (less frequently) suspends the current task or lowers its priority.
Asynchronous context switches occur when an ISR:

q q
Synchronous context switches require saving fewer registers than asynchronous context switches, and so are faster.
5-12
A task which pends or delays or suspends itself is said to block.
ISR stands for Interrupt Service Routine, the routine which executes when a hardware interrupt occurs. Such a routine executes in preference to any task unless interrupts are locked out.
Priority Scheduling
Different application jobs may have different precedences, which should be observed when allocating the CPU. Preemptive scheduling is based on task priorities chosen to reect job precedence. The highest priority task ready to run (not pended or delayed) is allocated the CPU. Rescheduling can occur at any time as a result of: Kernel calls Interrupts (e.g., system clock tick) The context switch is not delayed until the next system clock tick.
q q
5-13
Reschedules do not occur merely because a task has been executing for a long time. (See, however, the discussion of round-robin scheduling on subsequent slides).
When an interrupt causes a reschedule, it is because the interrupt service routine called a kernel function. A special case of this is the processing of timeouts and delays which occurs on every system clock tick interrupt.
The precedence of a job may be more determined by timing requirements than by the jobs "intrinsic importance," which is often nebulous.
Priority Based Preemption

High Priority Task A
Event Event
Priority
Med. Priority Task B
Low Priority Task C

Time
Equal priority tasks wont preempt each other (by default).

5-14
Rescheduling occurs if
q q
The currently running task pends or delays. A task of higher priority becomes ready.
When a task of higher priority takes the CPU away from the current task, it is preempting that running task.
If task B never blocks or pends, then task C will never run.
Round-Robin Scheduling
Time Slice Period (Constant - Programmable)
A
Equal Priority
A B C D
Time
B C D
5-15
Tasks A to D (same priority) share the CPU on an equal basis.
Round-robin mode makes all tasks of the same priority share the CPU fairly.
Slicing Time
To allow equal priority tasks to preempt each other, time slicing must be turned on:
kernelTimeSlice (ticks)
If ticks = 0, time slicing is turned off. Priority scheduling always takes precedence.
q
Round-robin only applies to tasks of the same priority. Round-robin rescheduling can only happen every few clock ticks.
Priority-based rescheduling can happen any time.

q
5-16
When time-slicing is on, it is on globally for tasks of all priorities. If the tasks of priority 100 use round robin to share the CPU equally amongst themselves, then the tasks of priority 120 must also use round robin to share the CPU equally amongst themselves.
Ticks is specied in system clock ticks. To get the clock frequency (in Hz):
-> clockRate = sysClkRateGet( )
Performance Enhancements
All tasks reside in a common address space. RAM text data bss fooLib
int fooVal; void fooSet (int x) { fooVal = x; } tTaskB fooSet (99) tTaskA fooSet (4)
All tasks run in supervisor (privileged) mode.
5-17
In UNIX or NT, a process has its own memory locations for data and bss but shares text with all other processes executing the same code.
In VxWorks, when a task accesses the text, data, or bss segments of a module, it accesses the same physical memory locations as any other task using the same code.
All tasks reside in a common address space. + Makes intertask communication fast and easy. + Makes context switch faster (dont need to save and restore virtual address contexts). - A deviant task can corrupt other tasks.
All tasks run in supervisor (privileged) mode. + No system call overhead. All VxWorks facilities are invoked as normal subroutines.
Multitasking Facilities
Device Device
Interrupt
Network
Interrupt
Task
ISR
Task
Buffer
Task
Task
5-18
Picture above represents an overview of the VxWorks multitasking facilities:

q q
Message passing queues for intertask communication within a CPU Network routines for intertask communication between CPUs Semaphores to protect data which is shared by tasks Timers and other interrupts to trigger task execution I/O system facilities to read/write data to hardware devices
How VxWorks Operating System Meets Real-time Requirements

Able to control many external components
q q
Multitasking allows solution to mirror the problem. Independent functions are assigned to different tasks. Intertask communication allows tasks to cooperate. Tasks are light-weight, enabling fast context switch. No system call overhead. Preemptive priority scheduling assures response for high priority tasks.
High speed execution

q q
Deterministic operation
q
5-19
Introduction 5.2 Task Basics Task Control Error Status System Tasks
5-20
Task creation Task names and ids Task priorities Task stacks Task options
Task deletion Deletion safety Resource reclamation
Overview
Low level routines to create and manipulate tasks are found in taskLib. A VxWorks task consists of:
q
A stack (for local storage of automatic variables and parameters passed to routines). A TCB (for OS control).
Do not confuse executable code with the task(s) which execute it:
q q
Code is downloaded before tasks are spawned. Several tasks can execute the same code (e.g., printf( )).
5-21
VxWorks tasks are similar to threads in process-model systems. (However, there will be differences between the threads of any particular implementation and VxWorks tasks.)
Creating a Task
taskSpawn
Stack
TCB
entry
foo ( ) { ... }
5-22
To create a task, VxWorks must:

q
Allocate memory for the stack and TCB from a memory pool. The taskSpawn() function allocates these in a single contiguous block. Initialize the stack (e.g., create an initial stack frame with arguments passed to the task). Initialize the TCB (e.g., store a pointer to the entry point function in the TCB; set the saved PC to the address of the wrapper routine vxTaskEntry which will call the entry point function; initialize the stack pointer; etc.). Put task into ready queue.
Creating a Task
int taskSpawn (name, priority, options, stackSize, entryPt, arg1, ..., arg10)
name Task name, if NULL gives a default name. priority Task priority 0-255. options Task options e.g. VX_UNBREAKABLE. stackSize Size of stack to be allocated in bytes. entryPt Address of code to start executing (initial PC). arg1, ..., arg10 Up to 10 arguments to entry-point routine. Returns a task id or ERROR if unsuccessful.
5-23
Example: newTid = taskSpawn (tMyTask, 150, 0, 20000, myRoutine, arg1, arg2, 0, 0, 0, 0, 0, 0, 0, 0)
The sp( ) shell built-in is equivalent to taskSpawn( ) called with default parameters.
Task IDs
Assigned by kernel when task is created. Unique to each task. Efcient 32-bit handle for task. May be reused after task exits. A task id of zero refers to task making call (self). Relevant taskLib routines: taskIdSelf( ) taskIdListGet( ) taskIdVerify( )
Get ID of calling task. Fill array with IDs of all existing tasks. Verify a task ID is valid.
5-24
Note: use of taskIdListGet( ) and taskIdVerify( ) may generate race conditions.
Task Names
Provided for human convenience.
q
Typically used only from the shell (during development). Within programs, use task Ids. Promotes interpretation as a task name. Default name is a t followed by an ascending integer.
By (often ignored) convention, task names start with a t.

q q
Doesnt have to be unique (but usually is). Relevant taskLib routines: taskName( ) taskNameToId( )
Get name from tid. Get tid from task name.

Wind River Systems
Copyright Wind River Systems
5-25
When the WDB agent is in task mode, tasks spawned with the WindSh built-in sp( ) are given a name sMuN, where the integer M numbers the shell instance and N increments each time sp( ) is used in that shell. Thus, even the WindSh shell does not always obey the (soft) task naming convention!
Task Priorities
Range from 0 (highest) to 255 (lowest). Determining how to set task priorities is a difcult subject, and beyond the scope of this course. However:
q
Timing requirements rather than hazy ideas about task importance should govern priorities. A substantial body of theory exists.
One can manipulate priorities dynamically with:
taskPriorityGet (tid, &priority) taskPrioritySet (tid, priority)

q
Doing so may make your applications behavior more difcult to analyze.

5-26
For debugging, a tasks priority should be lower than the WDB agent tasks priority to ensure that the Tornado tools can control and debug the task. Further, communicating with the WDB agent via a network connection will only be possible if the network task tNetTask gets a chance to run. For more information on VxWorks system tasks, see the System Tasks section of this chapter.
A nice introduction to scheduling theory is provided in chapter 13 of Burns and Wellings, Real-Time Systems and Programming Languages. 2nd Ed., Addison Wesley Longman, 1997. ISBN 0-201-40365-X
A more encyclopaedic treatment is provided in Klein, et. al., A Practitioners Handbook for Real-Time Analysis: Guide to Rate Monotonic Analysis for Real-Time Systems. Kluwer Academic Publishers, 1993, ISBN 07923-9361-9. This book assumes previous experience with real-time development and RMA.
Task Stacks
Allocated from system memory pool when task is created. Fixed size after creation. The kernel reserves some space from the stack, making the stack space actually available slightly less than the stack space requested. Exceeding stack size (stack crash) causes unpredictable system behavior.
5-27
Once the stack is overwritten, the integrity of the system is lost. The output of checkStack( ), on the next page, illustrates this, indicating that the task name of the third task has been lost.
Each byte in a tasks stack is lled with 0xee when the task is created. The checkStack( ) function searches from the end of the stack for this value in order to nd the maximum stack usage.
VxSim targets add 8000 bytes to the requested stack size, to deal with simulated interrupts, which are handled on the stack of the current task.
Stack Overows
To check for a stack overow use the Browser:
q q
Press the check-stack button: Examine the high water mark indicator in the stack display window.
High water mark indicator. (UNIX) Current usage shown by shaded bar and number inside.
High water mark shown by shaded bar. (Windows) Current usage shown by number inside bar.
5-28
From the shell:
-> checkStack (taskNameOrId)
If taskNameOrId is 0, summarize for all tasks.
A target-based implementation of checkStack() is available in wind/target/src/usr/usrLib.c.
Task Options
Can be bitwise ored together when the task is created:
VX_FP_TASK VX_NO_STACK_FILL VX_UNBREAKABLE VX_DEALLOC_STACK
Add oating point support. Dont ll stack with 0xees. Disable breakpoints. Deallocate stack and TCB when task exits (automatically set for you).
Use taskOptionsGet( ) to inquire about a tasks options. Use taskOptionsSet( ) to unset VX_DEALLOC_STACK.
5-29
Options are dened in taskLib.h. is set by taskSpawn() even if this bit is not present in the passed task options. It is not set by the taskInit() function, which allows you to specify the locations of a tasks stack and TCB (possibly in statically allocated memory), and creates the new task in a suspended state.
VX_DEALLOC_STACK VX_SUPERVISOR_MODE
q
is an obsolete option.
You may or may not see this option when calling taskOptionsGet( ). All tasks run in supervisor mode, regardless of this option. is an obsolete option. Tasks can now use buffered I/O regardless of this option.
VX_STDIO
q
Task Creation
During time critical code, task creation can be unacceptably time consuming. To reduce creation time, a task can be spawned with the VX_NO_STACK_FILL option bit set. Alternatively, spawn a task at system start-up which blocks immediately, and waits to be made ready when needed.
5-30
We will look at routines allowing a task to pend later in the course.
Task Deletion
taskDelete (tid)
Deletes the specied task. Deallocates the TCB and stack.
exit (code)
Equivalent to a taskDelete( ) of self. code parameter is stored in the TCB eld exitCode. TCB may be examined for post-mortem debugging by
q q
Unsetting the VX_DEALLOC_STACK option or, Using a delete hook.

5-31
The exit( ) routine is called automatically if a task returns from its entrypoint function.
In general, programmatically deleting another task is risky, because it is often impossible to know whether it is safe to do so, given that a task thus deleted could have had an exclusive lock on a resource which would thereby never be released, and left in an inconsistent state as well. This issue will be discussed further in a later chapter.
Resource Reclamation
Contrary to the philosophy of sharing system resources among all tasks. Can be an expensive process, which must be the applications responsibility. TCB and stack are the only resources automatically reclaimed. Tasks are responsible for cleaning up after themselves.
q q
Deallocating memory. Releasing locks on shared resources. Closing les which are open. Deleting child tasks when parent task exits.
5-32
In VxWorks all tasks are peers, with no strict parent-child relationship as exists in UNIX and other operating systems: VxWorks does not record which task spawned a given task. However, a conceptual parentchild relationship may exist, as in the case of a concurrent server application, wherein a server task spawns subordinate tasks for concurrent processing of client requests.
Introduction Task Basics 5.3 Task Control Error Status System Tasks
5-33
Restart
Suspend/Resume
Delay
Task Variables and Task Hooks
Task Information
Task Restart
taskRestart (tid)
Task is terminated and respawned with original arguments and tid. Usually used for error recovery.
5-34
If a task has modied the arguments passed to its entry point function, it may be restarted with either the modied values or the original values, depending on the target architecture, the number of arguments actually used, and the level of compiler optimization. If the task has changed priority or options since it was rst started, its original priority and options will not be restored.
If a task tries to restart itself, the work of doing this is actually handled by a new task of priority 0 named tRestart which is spawned for just this purpose. The tRestart task terminates after restarting the original task. The task tExcTask is not involved.
Task Suspend/Resume
taskSuspend (tid)
Makes task ineligible to execute. Can be added to pended or delayed state. It is safest to have a task suspend itself.
taskResume (tid)
Removes suspension. Usually taskSuspend() and taskResume() are used for debugging and development purposes.
5-35
Task Delay
To delay a task for a specied number of system clock ticks:
STATUS taskDelay (ticks)

To poll every 1/7 second:
FOREVER { taskDelay (sysClkRateGet( ) / 7) ... }
q
Accurate only if clock rate is a multiple of seven ticks/second. Can suffer from drift.
Use sysClkRateSet( ) to change the clock rate.

5-36
sysClkRateGet ( ) and sysClkRateSet ( ) are part of the BSP library sysLib. They may be implemented in either sysLib.c, or in a clock chip driver under target/src/drv/timer which might be shared among several BSPs.
Changes the task state from ready to delayed.
Reentrancy and Task Variables

If tasks access the same global or static variables, the resource can become corrupted (called a race condition). Possible Solutions:
q q
Use only stack variables in applications. Protect the resource with a semaphore. Use task variables to make the variable private to a task.
Task Variables cause a 32-bit value to be saved and restored on context switches, like a register. Caveat: task variables increase context switch times. See the taskVarLib manual pages for details.
5-37
Because task variables increase context switch times, they should be avoided when possible. They are intended for use when the interface to non-reentrant process model legacy code must be preserved.
Task variables can cause VxWorks to save and restore an arbitrary number of 32-bit, global or static variables on context switches. An application requiring many task variables should: 1. Dene all of its task variables in a structure. 2. Access this structure through a global or static pointer 3. Make this pointer the task variable. 4. Have each task allocate its own structure Now VxWorks need save and restore only a single task variable.
Some resources, such as memory shared for inter-task communication, should be protected with semaphores rather than with task variables.
Task Hooks
User-dened code can be executed on every context switch, at task creation, or at ask deletion: taskSwitchHookAdd ( ) taskCreateHookAdd( ) taskDeleteHookAdd ( ) VxWorks uses a switch hook to implement task variables. See manual pages on taskHookLib for details.
5-38
The hook tables have space for 16 switch hooks, 16 create hooks, and 16 delete hooks. VxWorks facilities may take up some of the available hooks. For instance, fppLib makes use of a create hook for oating point support; envLib makes use of both a create hook and a delete hook; the WDB agent and the ansiStdio library make use of delete hooks; the WDB agent also uses switch hooks to manage task-specic breakpoints and stepping.
Task switch hooks and create hooks are called in the order in which they were installed. Task delete hooks are called in the reverse of the order in which they were installed.
Create hooks run in the context of the creating task. Delete hooks run in the context of the deleting task, or tExcTask if a task exits or otherwise tries to delete itself. Switch hooks run in a minimal context in which only a few VxWorks routines may be legitimately called.
Task Information
ti (taskNameOrId)
Like i( ), but also displays:
q q
Stack information Task options CPU registers FPU registers (if the VX_FP_TASK option bit is set).
Can also use show ( ):
-> show (tNetTask, 1)
5-39
Task Browser
To obtain information about a specic task, double-click on the tasks summary line in the main task browser display, or enter the tasks ID in the Show box.
5-40
What is POSIX?
Originally, an IEEE committee convened to create a standard interface to UNIX for:
q q
Increased portability. Convenience.
VxWorks supports almost all of the 1003.1b POSIX Realtime Extensions. The POSIX real-time extensions are based on implicit assumptions about the UNIX process model which do not always hold in VxWorks. In VxWorks,
q q
Context switch times are very fast. Text, data, and bss segments are stored in a common, global address space.
5-41
POSIX is an acronym for Portable Operating System Interface (The X was added to make it UNIXish.).
POSIX standard 1003.1b was formerly called 1003.4.
What does VxWorks Support?

Library aioPxLib semPxLib mqPxLib mmanPxLib schedPxLib sigLib timerLib, clockLib dirLib Description Asynchronous I/O POSIX Semaphores POSIX Message Queues POSIX Memory Management POSIX Scheduler Interface POSIX Signals POSIX Timer/Clock Interface File/Directory Information
5-42
Of the POSIX 1003.1b real-time extensions, the following functions are not presently supported: aio_fsync( ) fchmod( ) fsync( ) fdatasync( ) mmap( ) munmap( ) mprotect( ) msync( ) shm_open( ) shm_unlink( )
For more information about how to use the POSIX real-time extensions, consult the Programmers Guide, the VxWorks Reference Manual and the online man pages.
Introduction Task Basics Task Control 5.4 Error Status System Tasks
5-43
Error Status
Global integer errno is used to propagate error information:
q q
Low level routine detecting an error sets errno. Calling routine can examine errno to discover why the routine failed.
5-44
Code using errno should include errno.h.
Errno and Context Switches

TCB(Old) copy of pc copy of sp ... errorStatus 1. CPU pc sp ... errno 2. TCB(New) copy of pc copy of sp ... errorStatus
At each context switch, the kernel saves and restores the value of errno.
5-45
errno is part of tasks context. A tasks error status is saved and restored on each context switch just like a registers value:
q q
Error value for executing task is stored in the global variable errno. Error value for non-executing task is stored in tasks TCB.
Setting Errno
Lowest level routine to detect an error sets errno and returns ERROR:
STATUS myRoutine() { ... if (myNumFlurbishes >= MAX_FLURBISH) { errno = S_myLib_TOO_MANY_FLURBISHES; return (ERROR); } ... pMem = malloc (sizeof(myStruct)); if (pMem == NULL) { /* malloc() sets errno - dont redefine it */ return (ERROR) } ... }
5-46
Examining Errno
Examine errno to nd out why a routine failed.
if ( reactorOk( ) == ERROR ) { switch (errno) { case S_rctorLib_TEMP_DANGER_ZONE: startShutdown( ); break; case S_rctorLib_TEMP_CRITICAL_ZONE: logMsg(Run!); break; case S_rctorLib_LEAK_POSSIBLE: checkVessel( ); break; default:startEmergProc( ); } }
errno is only valid after an error occurs.

5-47
Interpreting Errno
VxWorks uses the 32-bit value errno as follows:
31 15 0
module
q
error number
VxWorks module numbers are dened in vwModNum.h. Each module denes its own error numbers in its header le. Module number 0x11 (dened in vwModNum.h to be memLib) and Error number 0x01 (dened in memLib.h to be not enough memory).
For example, an errno of 0x110001 would be:

q
5-48
Error Messages
VxWorks uses an error symbol table (statSymTbl) to convert error numbers to error messages. To obtain the error string corresponding to errno: { char errStr [NAME_MAX]; strerror_r (errno, errStr); ... } To print the error message associated with an error number to the WindSh console:
-> printErrno (0x110001)

S_memLib_NOT_ENOUGH_MEMORY
5-49
printErrno( ) is a WindSh primitive. With no argument, it prints the errno value for the task which executed the most recent target function call from the shell. A target-based version is available in target/src/usr/ usrLib.c.
NAME_MAX is dened in limits.h, and strerror_r() is declared in string.h.
The routine perror( ) may be used to print out the error string corresponding to the calling tasks current errno value on STD_ERR.
User-Dened Error Codes

To allow strerror_r() to support your error messages: 1. Create a user header le directory. 2. Create a le xxModNum.h in the user header directory: #define M_myLib (501 << 16) 3. Dene error macros in your header les (which must be in the user header directory): #define S_myLib_BAD_STUFF (M_myLib|1) 4. Rebuild the system error table, statTbl.o. 5. Include the component development tool components > symbol table components > error status table in VxWorks. Add statTbl.o to the EXTRA_MODULES macro. 6. Rebuild VxWorks.
5-50
VxWorks reserves the rst 500 module numbers.
Your error macro must be dened as S_xxx.
To rebuild the system error table, do the following
1. Execute makeStatTbl : (UNIX) makeStatTbl systemHeaderDir userHeaderDir > statTbl.c (Windows) makeStatTbl systemHeaderDir userHeaderDir where systemHeaderDir is the path to the target/h subdirectory of the Tornado tree.
2. Compile the resulting le statTbl.c to produce statTbl.o.
The work of building the error table and linking it with VxWorks may be automated using the project facility, with a makele extension. A detailed procedure is provided as an advanced lab.
Introduction Task Basics Task Control Error Status 5.5 System Tasks
5-51
This section provides an overview of VxWorks system tasks.
System Tasks
Task Name tUsrRoot Priority 0 Function First task. Initializes included facilities, spawns user application, and exits. Message logging. Server which executes miscellaneous task-level functions at high priority. WDB run-time agent. Task-level network functions. FTP server.
Wind River Systems
tLogTask tExcTask
0 0
tWdbTask tNetTask tFtpdTask

3 50 55
Copyright Wind River Systems
5-52
These tasks are started when VxWorks boots.
Summary
Real-time multitasking requirements:
q q
Preemptive priority-based scheduler Low overhead OS control information (priority, stack size, options, state, ...). Saved CPU context (PC, SP, CPU registers, ...). Priority Stack size Options
Task properties stored in tasks TCB.

q
taskSpawn( ) lets you specify intrinsic properties:

q q
5-53
Summary
Task manipulation routines in taskLib:
q q
taskSpawn/taskDelete taskDelay taskSuspend/taskResume ti/show Task Browser errno Task variables Task hooks
Task information
q q
Additional task context:

q q
5-54

5 Multitask PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

5 Multitask PDF

Загружено:

Авторское право:

Доступные форматы

Chapter

Tornado Training Workshop

Copyright Wind River Systems Wind River Systems

Tornado Training Workshop

Copyright Wind River Systems Wind River Systems

Tasks and task states

Tornado Training Workshop

Copyright Wind River Systems Wind River Systems

Requirements of a Real-time System

High speed execution:

Tornado Training Workshop

Copyright Wind River Systems Wind River Systems

Tornado Training Workshop

Copyright Wind River Systems Wind River Systems

How do we design a system to control a robot arm?

Tornado Training Workshop

Copyright Wind River Systems Wind River Systems

Disadvantages of unitasking approach:

A specied time delay An event (e.g. an interrupt)

Tornado Training Workshop

Copyright Wind River Systems Wind River Systems

READY / EXEC PENDED

DELAYED & SUSPENDED

PENDED & DELAYED & SUSP.

DELAYED PENDED & DELAYED

Tasks may, additionally, be suspended:

Tornado Training Workshop

Tornado Training Workshop

Copyright Wind River Systems Wind River Systems

Types of Context Switches

Asynchronous context switches occur when an ISR:

A task which pends or delays or suspends itself is said to block.

Tornado Training Workshop

Copyright Wind River Systems Wind River Systems

Priority Based Preemption

Med. Priority Task B

Low Priority Task C

Equal priority tasks wont preempt each other (by default).

If task B never blocks or pends, then task C will never run.

Tornado Training Workshop

Copyright Wind River Systems Wind River Systems

Tasks A to D (same priority) share the CPU on an equal basis.

Priority-based rescheduling can happen any time.

Tornado Training Workshop

Copyright Wind River Systems Wind River Systems

-> clockRate = sysClkRateGet( )

All tasks run in supervisor (privileged) mode.

Tornado Training Workshop

Copyright Wind River Systems Wind River Systems

Tornado Training Workshop

Copyright Wind River Systems Wind River Systems

Picture above represents an overview of the VxWorks multitasking facilities:

How VxWorks Operating System Meets Real-time Requirements

High speed execution

Tornado Training Workshop

Tornado Training Workshop

Copyright Wind River Systems Wind River Systems

Task deletion Deletion safety Resource reclamation

Tornado Training Workshop

Copyright Wind River Systems Wind River Systems

Tornado Training Workshop

Copyright Wind River Systems Wind River Systems

To create a task, VxWorks must: