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
Top Related