OS

1

Real-Time Operating System

2

salient features of RTOS

• Multitasking

• Intertask communication

• Hardware Interrupt Handling

3

Definitions

Task:

Program activated for execution

Multitasking:

Execution of threads interleaved on the basis of a scheduling algorithm.

4

Task Context Block• a thread of execution i.e the Program Counter• the CPU registers and (optionally)the floating point

registers• a stack for dynamic variables and function calls• I/O assignments for std input, output and error• a delay timer• a timeslice timer• kernel control structures• signal handlers• debugging and performance monitoring values  All code executes in a single common address space  

5

Task State Transitions

6

Task State Transition(Contd..)

7

Wind task Scheduling

• Priority based preemptive scheduling

( default algorithm )

• Round robin scheduling

8

Task Scheduler Control Routines

9

Preemptive Priority scheduling Tasks of higher priority can preempt the task currently being

executed on the CPU

•wind kernel has 256 priority levels •tasks are assigned a priority when created; •a task can change its priority using taskPrioritySet()

10

Round robin scheduling

Time slicing for tasks of same priority

11

RoundRobin Scheduling (Contd.)

• Round robin scheduling can be enabled with the routine kernelTimeSlice(), which takes a parameter for time slice, or interval

• a run time counter is kept for each task and incremented on every clock tick

• When the specified time slice interval is completed, the counter is cleared and the task is placed at the tail of the queue of tasks at its priority

• New tasks joining a priority group are placed at the tail of the group with a run-time counter initialized to zero

• If a task is preempted by a higher priority task during its interval, its run-time count is saved and then restored when the task is again eligible for execution

12

Preemption Locks• Prevent task context switching but not interrupt handling.• taskLock() and taskUnlock() routines can be explicitly

used to disable and enable the wind scheduler on a per task basis

• tasklock() routine disables the scheduler so that no priority based preemption can occur

• if the task explicitly blocks or suspends, the scheduler selects the next highest priority eligible task to execute

• when the preemption-locked task unblocks and begins running again, preemption is again disabled

• preemption locks are used to achieve mutual exclusion.

13

The taskLib Library• taskLib library contains routines for task creation, control

and information Task creation and Activation routines

taskSpawn() embodies the lower level steps of allocation, initialization and activation. Id = taskSpawn(name, priority, options, stacksize, main, arg1,….arg10);

14

The taskLib Library(Contd..) Task Names and ID’s Routines

Task name : 4 byte ASCII string

Task Id : 4 byte handle to the tasks data structures.

Task Id of 0 implies calling task

15

The taskLib Library (Contd.)

Task Names and ID routines (Contd..)• task names should be unique and must not conflict with the

globally visible routines or variable names

• VxWorks uses the convention of prefixing all task names started from the target with t and the task names started from the host with u

• if a NULL pointer is supplied for the name argument for taskSpawn(), VxWorks assigns a unique name of the form tN, where N is a integer that incremented by 1 each time an unnamed task is spawned

Note: In the shell the task names are resolved to their

corresponding task ID’s

16

Task Options• When a task is spawned, an option parameter is specified

by performing a logical OR operation on any of the following options listed .

• Task Options

tid = taskSpawn(“tMyTask”, 90, VX_FP_TASK, 20000, myFunc, 2387 , 0 ,0 ,0, 0, 0, 0, 0, 0, 0); creates a task that includes floating point operations.

17

Task Options (Contd..)

Task Option Routines• allows a task to be examined and altered after it

has been spawned

Task Option Routines ( defined in taskInfo.h )

18

Task Information Routines• Get information about a task by taking a snapshot of a

tasks context when called.

• The state of a task is dynamic and the information may not be current unless the task is known to be suspended

19

Task Deletion and Safety• Tasks can be dynamically deleted from the system.

• Memory that is allocated by the task during its execution is not freed when the task is terminated.

• A task must release all shared resources it holds before the application deletes the task

20

Task Deletion and Safety(Contd.)taskSafe() and taskUnsafe()   taskSafe() semTake ( semID, WAIT_FOREVER); /*block until semaphore available*/ : : critical region : semGive (semID); /*release semaphore*/ taskUnsafe();

 - mutual-exclusion semaphore offers an option for deletion safety.

21

Task Control Routines

22

Tasking Extensions

• to allow additional task-related facilities to be added to the system without modifying the kernel, wind provides task create, switch and delete hooks.

• These hooks allow additional routines to be invoked whenever a task is created, a task context switch occurs or a task is deleted .

23

Tasking Extensions ( Contd..)

Task Create, Delete and Switch Hooks

24

Tasking Extensions(Contd..) Routines that can be called by Task Switch Hooks• user installed switch hooks are called within the kernel

context and hence Switch hooks do not have access to all Vxworks facilities.

25

Task Error Status: errno

Errno is defined in 2 different ways :– as an underlying global variable called errno

– as a macro defined in errno.h; visible to all of

VxWorks except for one function

• The macro is defined as a call to a function __errno() that returns the address of the global variable, errno

• Breakpoints can be placed on the function __errno(), to determine where a particular error has occurred

• C programs can set the value of errno in the standard way

errno = someErrorNumber;

26

errno (Contd..)

Separate errno value for each task• In a multitasking environment, each task must see its own

version of errno

• errno is saved and restored by the kernel as part of each task context every time a context switch occurs

• ISRs also see their own versions of errno by saving and restoring errno on the interrupt stack as part of the interrupt enter and exit code provided automatically by the kernel

• The error code can be stored or consulted with direct manipulation of the global variable errno, regardless of the VxWorks context

27

errno ( Contd..)Error Return Convention• Many functions return only the status values OK(0) or

ERROR(-1)

• Some that return a nonnegative number also return ERROR to indicate an error

• Functions that return a pointer usually return NULL(0) to indicate an error

• A function returning such an error indication also sets errno to the specific error code

• Errno Is never cleared by VxWorks routines

28

errno ( Contd..)

• When a VxWorks subroutine gets an error indication from a call to another routine, it normally returns its own error indication without modifying errno

• The value of errno that is set in the lower-level routine remains available as the indication of error type

29

Task Exception Handling

• the default exception handler suspends the task that caused the exception and saves the state of the task at the point of exception

• the kernel and other tasks continue uninterrupted• tasks can attach their own handlers for certain

hardware exceptions through the Signal facility

30

Shared Code and Reentrancy• Shared code - a single copy of the code executed by

multiple tasks

• Reentrant code - a single copy of the routine can be called from several task contexts simultaneously without conflict

TASKS SHARED CODE

31

vxworks Reentrancy techniques

• adopted by a majority of VxWorks routines:

- dynamic stack variables -  global and static variables guarded by semaphores -  task variables• VxWorks I/O and driver routines are

reentrant 

32

VxWorks Reentrancy Techniques(Contd..)

Dynamic Stack variables:

Subroutines that have no data of their own work exclusively on dynamic stack variables i.e data provided by the caller as parameters.

Eg – The linked-list library lstLib

33

VxWorks Reentrancy techniques(Contd..)

Guarded global and static variables:• use of static data variables. Eg. The memory

allocation library memLib• mutual exclusion mechanism to prohibit tasks

from simultaneously executing critical portions of code; (semaphore facility provided by semLib)

34

VxWorks Reentrancy Techniques(Contd..)

Task Variables• allow 4 byte variable to be added to the tasks context, so

that the value of such a variable is switched every time a task switch occurs to or from the owners task

• each of the tasks treat a single 4 byte memory location as its own private variable

• taskVarAdd(), taskVarDelete(), taskVarSet(), taskVarGet() and taskVarInfo() routines provide this facility

• Context switching time is delayed by a few microseconds

35

Task Variables and Context switches

36

Multiple tasks with same routines

  Each task spawn creates a new task with its own stack and context.

  each task spawn can pass the main routine different parameters to the new task. In this case, the rules of reentrancy apply.

37

VxWorks System Tasks

The Root Task: tUsrRoot– the first task executed by the kernel– the entry point of the root task is usrRoot() in installDir/target/config/all/usrConfig.c

– initializes most VxWorks facilities – Spawns the logging task, the exception task, the

network task and the tRlogind daemon– the root task terminates and is deleted after all

initialization has occurred– User can add any necessary initialization to the root

task

38

VxWorks System Tasks (Contd..)The Logging Task: tLogTask– is used by VxWorks modules to log system messages without having to perform I/O in the current task context

The Exception Task: tExcTask– supports the VxWorks exception handling package by performing functions that cannot occur at the interrupt level– it must have the highest priority in the system– this task should not be suspended, deleted, or its priority changed 

39

VxWorks System Tasks (Contd..)

The Network Task: tNetTask

- handles the task-level functions required by the

VxWorks network

The Target Agent Task: tWdbTask

- is created if the target agent is set to run in task mode

- it services requests from the Tornado Target server

40

VxWorks System Tasks (Contd..)Tasks for Optional Components tShell• the target shell is spawned as this task if it has been included in the VxWorks configuration• any routine or task invoked from the target shell, rather than spawned, runs in the tShell context 

tPortmapd• this daemon is an RPC server that acts as a central registrar for RPC server running on the same machine

• RPC clients query the tPortmapd daemon to find out how to contact the various servers

41

VxWorks System Task(Contd..)Tasks for Optional components (Contd..) tRlogind• this daemon allows remote users to login to VxWorks with telnet, if target shell and rlogin facility have been included in VxWorks configuration• it accepts a remote login request from another VxWorks or host system and spawns the input task tRlogInTask and the output task tRlogOutTask• these tasks exist as long as the remote user is logged on• during the remote session, the shell’s (and any other task’s) input and output are redirected to the remote user• a tty-like interface is provided to the remote user through the use of the VxWorks pseduterminal driver ptyDrv

42

VxWorks System Task(Contd..)Tasks for Optional components (Contd..) tTelnetd• this daemon allows remote users to login to VxWorks with telnet, if target shell and telnet facility have been included in VxWorks configuration• it accepts a remote login request from another VxWorks or host system and spawns the input task tTelnetInTask and the output task tTelnetOutTask• these tasks exist as long as the remote user is logged on• during the remote session, the shell’s (and any other task’s) input and output are redirected to the remote user• a tty-like interface is provided to the remote user through the use of the VxWorks pseduterminal driver ptyDrv

43

VxWorks Intertask Communications

• Shared memory, for simple sharing of data• Semaphores, for basic mutual exclusion and

synchronization• Message queues and pipes, for inter-task

message passing within a CPU• Sockets and remote procedure calls, for

network-transparent inter-task communication• Signals, for exception handling

44

Shared Data Structures

Global variables, linear buffers, ring buffers, linked lists and pointers can be referenced directly by code running in different contexts

45

Mutual Exclusion

Methods include

• disabling interrupts,

• disabling preemption,

• resource locking with semaphores.

46

Interrupt locks and latency - the most powerful tool for mutual exclusion is the

disabling of interrupts - guarantees exclusive access to the CPU funcA() { int lock = intLock(); : critical region that cannot be interrupted intUnlock (lock); }

47

Interrupt Locks and Latency (Contd..)

- inappropriate as a general-purpose mutual exclusion method for most real-time systems as it prevents the system to responding to external events for the duration of these clocks

- can become necessary where mutual exclusion involves ISR’s

- duration of the interrupt lockouts should be short

48

Preemptive Locks and Latency - Disabling preemption offers a less restrictive form of mutual exclusion

- Pre-emption lock does not imply interrupt lock

funcA ()

{

taskLock();

: critical region that cannot be interrupted

taskUnlock();

}

- this method can lead to unacceptable real-time response

- Tasks of higher priority are unable to execute until the locking task leaves the critical region, even though the higher priority task is not itself involved with the critical region

49

Semaphores

- address the requirements of both mutual exclusion and task synchronization

- 3 types of wind semaphores

- binary

- mutual exclusion

- counting

50

Semaphore Control• single uniform interface provided for semaphore control

• Only the creation routines are specific to the semaphore type

51

Taking a Semaphore

52

Giving a semaphore

53

Mutual Exclusion Semaphores

- specialized binary semaphore designed to address issues inherent in mutual exclusion, including priority inversion, deletion safety and recursive access to resources

Behaviour of mutual exclusion semaphore is identical to that of a binary semaphore with the following exceptions

it can be used only for mutual exclusion

it can be given only by the task that took it

it cannot be given from the ISR

the semFlush() operation is illegal

54

Priority Inversion

- arises when a higher priority task is forced to wait an indefinite period of time for a lower priority task to

complete

55

Priority Inheritance Algorithm

- the “inheriting” task is protected from preemption by any intermediate priority tasks.

semId = semMCreate (SEM_Q_PRIORITY |SEM_INVERSION_SAFE); creates a mutual exclusion semaphore that uses the priority inheritance algorithm

56

Deletion Safety

mutual exclusion semaphore option

SEM_DELETE_SAFE

    - enables an implicit taskSafe() with each semTake(),

and a taskUnsafe() with each semGive()

   semId = semMCreate( SEM_Q_FIFO |

SEM_DELETE_SAFE);

protects the task from deletion while it has the semaphore

57

Recursive Resource Access• recursion is useful for a set of routines that must call each

other but that also require mutually exclusive access to a resource

• the mutual exclusion semaphore can be taken more than once by the task that owns it before finally being released

• before being released a mutual exclusion semaphore taken recursively must be given the same number of times it is taken.

• this is tracked by count that is incremented with each semTake() and decremented with each semGive()

58

Counting Semaphores• keeps track of the number of times the semaphore is given

• are useful for guarding multiple copies of resources

Counting semaphore example

59

Special Semaphore Options

• TimeOuts

- controlled by the parameter to semTake() that

specifies the amount of time in ticks that the task is

willing to wait in the pended state

- if the task succeeds in taking the semaphore within

the alloted time, semTake() returns OK

- the errno set when a semTake() returns ERROR due

to timing out before successfully taking the semaphore

depends upon the timeout value passed

60

Special Semaphore Options (Contd..)

• a semTake() with NO_WAIT(0) sets errno to

S_objLib_OBJ_UNAVAILABLE

• a semTake() with a positive timeout value returns

S_objib_OBJ_TIMEOUT.

• a timeout value of WAIT_FOREVER(-1) means wait

indefinitely

61

Special Semaphore Options(Contd..)

Queues

• based on FIFO or priority order • priority ordering better preserves the intended priority

structure of the system at the expense of some overhead in semTake() in sorting the tasks by priority

• a FIFO queue requires no priority sorting overhead and leads to constant-time performance

62

Special Semaphore Options (Contd..)

• selection of queue type is specified during semaphore creation with semBCreate(), semMCreate() or semCCreate().

• semaphore using the priority inheritance option (SEM_INVERSION_SAFE) must select priority-order queuing

63

Queues (Contd..)

Task Queue Types

64

Message Queues

• Primary intertask communication mechanism within a single CPU.

• Allow a variable number of messages, each of variable length to be queued

• any task or ISR can send messages to the message queue

• any task can receive messages from the message queue

• multiple tasks can send to and receive from the same message queue

65

Message Queues(Contd..)

Full Duplex Communication Using 2 Message Queues

66

Wind Message Queues

• this library provides messages that are queued in FIFO order but with an exception• there are 2 priority levels, and the messages marked as high priority are attached to the head of the queue

67

Wind Message Queues(Contd..) Timeouts :• when sending a message , timeout specifies how many

ticks to wait for buffer space to become available if no space is available to queue the message

• when receiving a message, timeout specifies how many ticks to wait for a message to become available, if no message is immediately available

• NO_WAIT(0) , indicates always return immediately• WAIT_FOREVER(-1) , meaning never time out the

routine

68

Wind Message Queues(Contd..)

Urgent Messages

• msgQSend() allows specification of the priority of a message as either normal (MSG_PRI_NORMAL) or urgent (MSG_PRI_URGENT)

• normal priority messages are added to the tail of the list

• urgent messages are added to the head of the list

69

Wind Message Queues(Contd..)

Displaying Message Queue Attributes• show() produces a display of the key message queue

attributes

70

Servers & Clients with MessageQueues

• message queues and pipes are used to implement a client server model

Client Server Communication using Message Queues

71

Pipes• are virtual I/O devices managed by the driver pipeDrv

• pipeDevCreate() creates a pipe device and the underlying message queue associated with the pipe

status = pipeDevCreate( “/pipe/name”, max_msgs,

max_length);

• tasks can use the standard I/O routines to open, read, write pipes and invoke ioctl routines

• ISR’s can write to a pipe but cannot read from a pipe.

• Pipes can be used with select() (message queues cannot)

72

Network Task Communication

Sockets

• an end point for communications between tasks• homogenous means of communication• can occur between VxWorks tasks and host

system processes in any combination

73

Network Task Communications (Contd..)

Remote Procedure Calls:• a facility that allows a process on one machine to call a

procedure that is executed by another process on either the same machine or a remote machine

• internally , RPC uses sockets as the underlying communication mechanism

• with RPC, VxWorks tasks and host system processes can invoke routines that execute on other VxWorks or host machines, in any combination

74

Intertask Communications(contd..)

Signals

• asynchronously alter the control flow of task

• Wind kernel supports two types of signal interface– UNIX BSD- style signals

– POSIX-compatible signals

75

Signals (Contd..) Basic Signal Calls

- the signal library initialization routine sigInit() must be called normally from usrInit() in usrConfig.c before interrupts are enabled

76

Signal Configuration

• the basic signal facility is included in VxWorks by default, with INCLUDE_SIGNALS

• before the application can use POSIX queued signals, they must be initialized separately with sigqueueInit()

• sigqueueInit() is called from usrInit() in usrConfig.c after sysInit() runs

77

Signal Configuration (Contd..)

• to initialize the queued signal functionality, define INCLUDE_POSIX_SIGNALS; it calls sigqueueInit() automatically

• sigqueueInit() allocates nQueues buffers for use by sigqueue(), which requires a buffer for each concurrently queued signal

• a call to sigqueue() fails if no buffer is available

78

Interrupt Service Code• hardware interrupts inform the system of an external event

• ISR’s in VxWorks run in a special context outside of any tasks context.

• interrupt handling involves no task context switch

Interrupt Routines provided in intLib and intArchLib

79

Connecting Application Code to Interrupts

• VxWorks provides the routine intConnect(), which allows C functions to be connected to any interrupt.

• the arguments to this routine are the byte offset of the interrupt vector to connect to, the address of the C function to be connected and an argument to pass to the function

80

Connecting Application Code to Interrupts (Contd..)

Routine Built by intConnect()

intConnect ( INUM_TO_IVEC (someIntNum), myISR, someVal);

81

Interrupt Stack• is allocated and initialized by the system at start-up

according to specified configuration parameters

• whenever the architecture allows it , all ISR’s use the same Interrupt Stack.

• It must be large enough to handle the worst case combination of nested interrupts

• On architecture that do not permit the use of a separate interrupt stack, ISR’s use the stack of the interrupted task

• checkStack() allows you to see how close your tasks and ISR’s have come to exhausting the available stack space

82

Special Limitations of ISRs• Stem from the fact that ISR does not run in a regular task

context

• ISR does not have a task control block and all ISRs share a single stack

• ISRs must not invoke routines that might cause the caller to block

• ISRs cannot call any creation or deletion routines

• ISRs must not perform I/O through VxWorks drivers

• Exception is the VxWorks Pipe driver which is designated to permit writes by ISRs

• ISR must not call routines that use a floating-point coprocessor

83

Routines that can be called by ISRs

84

Exceptions at Interrupt Level

• when ISR causes an exception, VxWorks stores the description of the exception in a special location in low memory and executes a system restart.

• VxWorks boot ROMs test for the presence of the exception description, if detected , displays it on the system console

• The e command in the boot ROMs redisplays the exception description

85

Reserving High Interrupt Levels

• To achieve zero latency response, VxWorks provides intLockLevelSet(), which sets the system-wide interrupt-lockout level to the specified level

• default is the highest level supported by the processor architecture

86

Additional Restrictions for ISRs

• ISRs connected to interrupt levels that are not locked out (either an interrupt level higher than that set by

intLockLevelSet(), or an interrupt level defined in hardware as non-maskable) have special

restrictions:

• the ISR can be connected only with intVecSet()

• the ISR cannot use any VxWorks OS facilities that depend on interrupt locks for correct operation

87

Interrupt-to-Task Communication

Techniques used to communicate from ISR to task level code

• shared memory and ring buffers – ISRs can share variables,buffers, and ring buffers with task-level code

• Semaphores – ISRs can give semaphores(except mutual-exclusion semaphores and VxMP shared semaphores) that tasks can take and wait for

• Message Queues – ISRs can send messages to message queues for tasks to receive (except for shared message queues using VxMP).The message is discarded if the queue is full

88

Interrupt-to-task Communication ( Contd..)

• Pipes – ISRs can write messages into pipes for tasks to read.Tasks and ISRs can write to the same pipes. The message is discarded if the queue is full .ISRs must not invoke any I/O routine on pipes other than write()

• Signals – ISRs can “signal” tasks, causing asynchronous scheduling of their signal handlers

89

Watchdog Timers• allows any C function to be connected to a specified time

delay

• are maintained as part of the system clock ISR

• normally, functions invoked by watchdog timers execute as interrupt service code at the interrupt level of system clock

• however if the kernel is unable to execute the function immediately, the function is placed on the tExecTask work queue

• Functions on this queue execute at a priority level of the tExecTask(usually 0)

90

Watchdog Timers (Contd..)

Watchdog Timer Calls provided by wdLib library

91

Asynchronous I/O• AIO is the ability to perform input and output operations

concurrently with ordinary internal processing

• enables the decoupling of I/O operations from the activities of a particular task when these are logically independent

• offers greater processing efficiency

To include AIO in the VxWorks configuration select INCLUDE_POSIX_AIO and

INCLUDE_POSIX_AIO_SYSDRV in the project facility VxWorks view

92

AIO Control Block• each of the AIO calls takes an AIO control block (aiocb)

as an argument• the calling routine must allocate space for the control

block which is associated with a single I/O operation• no two concurrent AIO operations can use the same

control block• the aiocb and the data buffers it references are used by the

system while performing the associated request• Therefore, after request for an AIO operation has been

made, corresponding aiocb must not be modified before calling aio_return()

• if a routine allocates stack space for the aiocb, that routine must call aio_return() to free the aiocb before returning.

93

AIO Control Block (Contd..)The aiocb structure is defined in aio.h and contains thefollowing fields:aio_fildes - file descriptor for I/Oaio_offset - offset from the beginning of the fileaio_buf - address of the buffer from/to which AIO is requestedaio_nbytes - number of bytes to read or writeaio_reqprio - priority reduction for this AIO requestaio_sigevent - signal to return on completion of an operation(optional)aio_lio_opcode - operation to be performed by a lio_listio() callaio_sys - VxWorks-specific data (non POSIX)

94

Using AIO

• aio_read(), aio_write(), lio_listio() initiate I/O operations

• lio_listio() allows the submission of a number of asynchronous requests at one time

• the actual I/O does not happen immediately after an AIO request

• therefore their return values only indicate if the AIO routine has been able to put the operation on the queue

• the return values generated after the execution of the I/O reflect the success or the failure of the I/O

95

Using AIO (Contd..)

• aio_error() – routine to get the status of the I/O operation (success, failure or in progress)

• aio_return() – routine to obtain the return values from the individual I/O operation

• Until an AIO operation completes, its error status is EINPROGRESS

• aio_cancel() – routine to cancel an AIO operation

96

AIO for periodic checks for completion

• A synchronous read to an empty pipe blocks and the task does not execute the write,

• In case of AIO, the read request is initiated and the process continued

• The following piece of code checks the status of the AIO requests periodically until both read and write complete

while (( aio_error (&aiocb_read) = = EINPROGRESS)|| (aio_error (&aiocb_write) = = EINPROGRESS ))

taskDelay(1);

97

Summary

• Basic OS• Exception handling• Shared code and reentrancy• Inter-task Communications• Semaphores• Message queues• Pipes• Network inter-task communication

98

Summary

• Signals

• Interrupt Service Code

• Asynchronous I/O

• Devices and Device Drivers in VxWorks

99

taskInfo.h library

ROUTINES taskOptionsSet( ) -change task options

taskOptionsGet( ) -examine task optionstaskRegsGet( ) -get a task's registers from the TCBtaskRegsSet( ) -set a task's registerstaskName( ) -get the name associated with a task IDtaskNameToId( ) -look up the task ID associated with a

task nametaskIdDefault( ) -set the default task IDtaskIsReady( ) -check if a task is ready to runtaskIsSuspended( ) -check if a task is suspendedtaskIdListGet( ) -get a list of active task IDs

Back

100

taskLib.h library

ROUTINES taskSpawn( ) - spawn a task

taskInit( ) - initialize a task with a stack at a specified address

taskActivate( )- activate a task that has been initialized

exit( ) - exit a task (ANSI)taskDelete( ) - delete a tasktaskDeleteForce( ) - delete a task without restrictiontaskSuspend( ) - suspend a tasktaskResume( ) - resume a tasktaskRestart( ) - restart a task

101

taskLib.h library

taskPrioritySet( ) - change the priority of a tasktaskPriorityGet( )- examine the priority of a tasktaskLock( ) - disable task reschedulingtaskUnlock( ) - enable task reschedulingtaskSafe( ) - make the calling task safe from

deletion taskUnsafe( ) - make the calling task unsafe from

deletion taskDelay( ) - delay a task from executingtaskIdSelf( ) - get the task ID of a running tasktaskIdVerify( ) - erify the existence of a tasktaskTcb( ) - get the task control block for a task ID

Back

102

taskShow.h library

ROUTINES

taskShowInit( ) - initialize the task show routine facility

taskInfoGet( ) - get information about a tasktaskShow( ) - display task information from TCBstaskRegsShow( ) - display the contents of a task's

facility

taskStatusString( ) - get a task's status as a string