ADDITIONAL TASKAfiRIBUTES

In addition to priority, executior state, arid suspension depth, the Nucleus maintains curent values of the following attributes for each existing task: containingjob, its register context, starting address of its exception handler (see Chapter 8), its exc€ption mode (see Chapter 8), whether or not it is an iotemrpt task (see Chapter 9) and whether the task uses the Numeric Extension Processor lNPXl.

3.7 TASKRESOURCES

When a task is created, the Nucleus takes any Íesources that it needs ar that time (such as memory for a stack) fiom the task's containingjob. If the task is subsequently deleted, these resources are returned to the iob.

3,8 SYSTEM CALLS FORTASKS \-/

The following system calls are provided for task manipulation:

. CREATE$TASK--creates a task and returns a token for it.

o DELETE$TASK--deletes a non-interrupt task from the srstem.

. SUSPEND$TASK-irìcreases a task's sùspension depth by one; suspends the task if it is not already suspended.

. RESUME$TASK--decreases a task's suspension depth by one; if the depth becomes zero and the task was suspended, it then becomes ready; if the depth becomes zero and the task was asleep-suspended, then it goes into the asleep state.

. SLEEP-places the caìIing task in the asleep state for a specified amount of time.

. GET$TASK$TOKENS--returns a token to the calling task for either the task, itsjob, its job's parameter object, or the root job, depending on which option is specified io the call.

. GET$PRIORITY-returrs the priority of the specified task. \--l . SET$PRIORiTY--sets a task's priority to the specified level.

For a complete list and explanation of the iRMX 1I Nucleus system calls, see the iRMfII Nucleus Ststem Calk Reference Manual.

Nucleus Usels Guide

4.1 INTRODUCTION

The iRMX II Nucleus provides exchanges to facilitate intertask communication,

syrichronization, and mutual exclusion. When a task uses an exchange, iî is always acting either as a se[der or as a receiver. There are three kinds of exchanges: mailboxes, semaphores, and regions. If the exchange is a mailbox, one task will send a message to the mailbox; another task will go to the mailbox to receive the object's message. If the

exchange is a semaphorc, either a tqsk is receiving units from the semaphore, or it is sending units to the semaphore. lf the exchange is a region, the data in the region can be accessed by only one task at a time, and this task cannot be deleted or suspended until it relinqui$hes control.

4.2 MAILBOXES

Mailboxes support furtertask communication. A serding task uses a mailbox to pass either a token or a m€ssage of up to 128 bytes to arolher task. For example, thc objoct might be that of a segnent containhg data needed by îhe receiving task.

4.2.1 Mailbox Queues

Each mailbox has two queues, one for tasks that are waiting to receive objects or

messages, the other for objects or messages that have been sent by tasks but have not yet been received. The Nucleus sees that waiting tasks receive objects or messages as soon as they are available, so, at any úefl time, at least one of the mailbox's queues is empry.

4.2.2 MailboxMechanics

'When

creating a mailbox, yoù must specit' whether the mailbox is a data mailbox or a message mailbox. Data mailboxes are manipulated with the system calls SEND$DATA and RECEI\B$DATA, whereas, message mailboxes are manipulated vr'ith the

SEND$MESSAGE and RECEM$MESSAGE system calls. If you try passing a message îo a mailbox with the wrong system call, for example sending a token with SEND$DATA, the Nucleus issues an E$TYPE exceotion code.

Nucleus Uset's Guide 4-1

EXCHANGE MANAGEMENT

When a task sends either a token or a data packet to mailbox, using the

SEND$MESSAGE or the SEND$DATA system call, one of two events occurs. If no tasks are waiting at the mailbox, the message is placed at the rear of the rnessage queue (which might be emp9. Message queues (objert or daîa queues) are processed in a first-in/first-out (FIFO) manner, so the message remains in the queue until it moves to the îront and is given to a task.

If there are tasks waiting, the receiving task, which has been adeep, goes eíther from the asleep state to the ready state or ftom the asleep-suspended state to the suspended state.

{ NOTE

jji If the receiving task has a higher priority than the sending taslq then the ii receiving task preempts the sender and becomes the runnmg task.

I

Wher a task attempts to receive a message from a mailbox via the

RECEM$MESSAGE or RECEM$DAT,{ system call, and îhe message qùeue at the mailbox is not empty, the task rec€ives the message immediately and remains ready.

However, if there are no messages at the mailbox one of two evenîs occurs:

. If the task specifier in the time$limit parameter that it is willing to rvait, it is placed in the mailbox's task queue and is put to sleep. If the desigoated waiting period elapses before the task gets a messagg the task is made ready and receives an E$TIME exceptional condition (see Appendix D for a list of error conditions).

. If the task specifies in the time$limit parameter that it is not willing to wait, it remains ready and receives an E$TIME exceptional condition.

A task has the option, when using the SEND$MESSAGE system call, of speci&ing that it wants acknowledgment from the receiving task. Thus, any task using the

RECEIVE$MESSAGE system call should check to see if an ackrowledgnent has been requested. This option is riot available to a task using the SEND$DATA system call, For details, see thdescriptioÌ of the s)stenÌ calls i,i the Ertended. iRMX II Nucleus Estern C alls Refere nce M anual,

As stated earlier, îhe message queue for a mailbox is processed in a FIFO manler.

However, the task queue of a mai.lbox can be either FIFO or priority-based, with higher-priority tasks toward the front of the queue. When a task creates a mailbox, the task specifies which kind of task queue the mailbox is to have.

4.2.3 High-Performance Portion of Obiect Queue

The object queue of each mailbox is divided into two portions: a high-performance portion and an overflow portion. The high-performance portion is direcdy associated with each mailbox, while the overflow portion is created by the operating system as needed.

Nucleus Uset's Guide

EXCHANGE MANAGEMEM

A task, when oearing a mailbox with CREATE$MAILBOX, can speciry the rumber of objerts the high-performance portion can hold, from 4 to 60. By using this high-p€rformance portion of the object message queue, the task can grea y iroprcve the performance of SEND$MESSAGE and RECEM$MESSAGE when these calls actually get or place objerts on the queue (the high-performance portion has no effect when tasks are alr€ady waiting at the task queue). When more objects are queued at a mailbox than the high-performance portion can hold, the objeats overflow into an efra buffer that holds up to 100 messages. The ovedlow buffer is not deleted ulltil the object message queue empties. Thus, the average slowdown experienced when the high-performance portion overllows is almost oegligible.

The high-performance portion has high speed because the Nucleus allocates memory for it while qeating the mailbox. The Nucleus allocaîes this memory perma[enîly to the mailbox, evcn if no objects are queued there. No space ís allocated for the overllow portion of the queue until the space is needed to contain objects. However, because an overllow buffer is not created for every send/receive message, but rather for every 100 messages, there is alrnost rio effect on performance. Performance is affected only in the worst-case when a SEND$MESSAGE sysrem call causes the allocation of an overflow buffer. In this case, extra time is required for the allocation. If you know the number of objects you will have, it is advisable to configure the high-performanc€ portion to hold them.

4.2.4 System Calls for Mailboxes

The following system calls manipulate mailboxes:

. CREATE$MAILBOX-creates a mailbox arid retùms a tokén.

e DELETE$MAILBOX-deletes a mailbox from îhe system.

. SEND$DATA-sends a data packet of up to 128 bfes to a mailbox.

. SEND$MESSAGE -sends an object to a maflbox.

r RECEIVE$DATA-receives a data packet from a mailbox; the task has the option of waiting if no data packets are present.

r RECEIVE$MESSAGE-receives an object from a mailbox; the task has the option of waiting if no objects are present.

For a complerc lisî and explamtion of the iRMX II Nucleus system calls, see the Ettekded

|RMX II Nucleur S)stem Calk Refercnce Manual.

Nudeùs Uset's cuide 4-3

EXCIIA.NGE MAN,I.GEMENT

4.3 SEMAPHORES

A semaphore is a custodian of abstract units. A task uses a semaphore €ither by

requesting a specific number of units ftom it via the RECEM$UNITS sysîem call or by releasing a specific number of units to it via the SEND$UNnS system call. Although these operations do not support communicatiorì of data, they facilitate mutual exclusion, slnchronization, and resource allocation,

4.3.1 Semaphore Queue

Semaphores have only one queue, a task queue. The task queue is either FIFO or priority-based. The queueing scheme to be used ìs specified for each semaphore at the time of ifs creation.

4.3.2 SemaphoreMechanics

Because tasks can reqùest more than one unit, a semaphore might simultaneously have both tasks in its queue and units in its custody. That scheme is best uùderstood by

imagining that the semaphore is îrying, at all times, to satisù/ the requ€st of the task which is at the front of the semaphore's task queue. Only when it can provide as many units as the task requested does it award units, and then it does so immediately. A request made to a semaphore is either granted in full or it is not graùted at all.

When a task uses the CREATE$SEMAPHORE system call, it mùst supply two values. ,,,/

One value specifies the initial numbcr of units to be in the new semaphoîe,s custoù. The other value sets an upper limit on the nùmber of ùnits that the semaphore is allowed to keep at any given time. The lower limit is automatically zero,

When a task requests units fiom a semaphore via the RECEIVE$UMIS system call, the request must be within the specified ma,rimum for that semaphore; otherwise, the request is invalid and causes an E$LIMIT exceptional condition. If a task,s request for units is valid and if the size of the request is within the semaphore's current supply of units arid,

the task is at the fronî of the semaphore's task queue (or would be if queued), then the \_/

request is granted immediarely and the task remains .eady. Otherwise, one of the following applies:

. If the task specifies in its time$limit parameter that it is willing to wait, it is placed in the semaphore's task queue and is put to sleep. If the designated waiting period eÌapses before the task gets iîs requested units, the task is made ready and receives an E$TIME exceptional condition.

. If the task specifies in its time$limit parameter that it is not willing to wait, it reÌnains ready and receives an E$TIME exceptional condition.

4-4 Nucleus Usefs Guide

EXCIIANGE MANAGEMENT

For example, suppose that two tasks, A and B, arc waiting at a semaphore, with A at the front of the qùeue. The semaphore has no units, A wants 3 units, and B wants 1 ùnit. The follovr''ing thrce separate cases illùstmte the tnechanics of the semaphore:

. If the semaphore is sent 2 units, both A and B remain asleep in the semaphore's queue. Note that B's modest request is not satisfied because A is ahead of B in the queùe.

. Ifthe semaphore is sent 3 units, A receives the units and awakeng while B remains asleep io the queue.

. If the semaphore is sent 4 units, A and B both receive their requested ùnits and are awakened (A is awakened first).

When a task sends units to a semaphorg îhe task remains ready. Sending uniîs to a semapho.e causes ari E$LIMIT exceptional condition if it pushes the semaphore,s supply above the designated maximum. The number of units in the custody of thssemaDhore remains unchansed.

NOTI

A task sending units to a semaphore can be pre-empted by a higher priority task becoming ready as a result of receiving its requested units.

4.3.3 System Calls for Semaphores

The following system calls manipùlate semaphores:

. CREATE$SEMAPHORE-CieateS a semaphore and reîums a token for it.

. DELETE$SEMAPHORE-deIe!e$ a semaphore from îhe system.

. SEND$UMTS-adds a specific number of units to the supply of a semaphore.

r RECEIVE$UNITS-asks for a specific number of units from a semaphore.

For a complete list and explanation of the iRMX Il Nucleus system calls, see the Extended

|RMX II Nuclew Systeh Calls Reference Marual.

4.4 REGIONS

A region is an iRMX lI obje€t thar tasks can use ro guard a specific collection of shared data. Each task desiring access to shared data awaits its turn at the region associated with thaî data. When the task currently usìng the shared data no longer ne;ds access, it notifies the operating system, which then allows the next task to access the shared data.

Regions should be restricted to specific uses. Misuse of regions can have profoùrid affects on your application system.

Nucleus Usefs Guide 4.5

EXCIIANGE MANAGEMENT