intel'
E X T E N D E D i R M X @ I I . 3
OPERATING SYSTEM D O C U M E N T A T I O N
V O L U M E 2 U S E R ' S G U I D E S
O.der Number: 461845-001
r !
Intel Corporation 3065 BowersAvenue Santa Clara, Californla 95051
Copyright o 1988, Intel Corporation, Ail Rights Reserved
In locationB outside the Uúited Stata6, obtain ailditionsl copi€s of Iniel docuúentation by contecting your jocal Iniel sales ofice. For yoù conveni€.ce, int€rnaiionsl sales ofiice rddr€ss€s arc locateddircctlybeforetlìe readÈr.€ply.ardiirtrùÙàckollhe nuîual,
The infornation in Lhis do.uhent is subj€ct to change wiihoui noiice.
Inrel Corporation makes no warranty ofany kind with regard io rhi6 mat€rial, inclùding, but not Ìimit€d to, the impiied ù arrantie6 of merchantsbility and Iithess fo. a parlicùlù pufpose. Iniel Co.poration assumes no responsibility lo. any errors ihai may appear in ihi6 documeùt. Intel Corporation makes no connitmentto update or to keep currentthe informùtioúcontained iù this
Iùtel Corporation assune6 no respohsibility lor the se of any circuilry other rhan circuit.y ehbodied in an Intel prodùct. Noothercircuitpatentlicensesare implied-
Int€l $ftware p.oducts a.e copyrighted by and shall renain the property of Ìntel Corpofaiion.
Use, duplicaiio! or di6closure is subject to restrictions stated in Intel's soltwaré li.ebse, or as detinedinASPRT 104.9 (a)(9).
No paú olthis document mèy be copied or rèproduced in any form or by any means without prior wÌitt€n cons€nt oIInt€l Corporation.
The fouowins are tradeúÉrks of Intel Corporation and ik amliaies and nay be Èed only 10 id€ntily Intel producls:
iPSC iRMX iSBC
isBx
iSDM issB iSXM MCS
MICROMAINFRAME MULTIBUS
MULTICHANNEL MULT!MODULE
XENIX, MS-DOS, Multiplan, and Microsoft are t.ademarks ofMicrosolt Co.poraiion. SNIX is a trademark of Bell Laboratori€s. Ethe.net is a trademsrl< of X€rox Coeorstion. Cenirorics is a rrad€mark of Centronics Data CoDDuter Corpo.ation. Chassis Trak is a tradenark of ceneral Devices Company, tnc. yAX and VMS are iradeùarts of Digital Equipm€nt Corporarion.
Sma.tmodem 1200 5nd Hayes are traalemarls otH.yes Mic.ocompute. Produck,Inc. IBM is a reqisiered trademark oflnt€.nltionÈl B$iness Machi@s, Softscope is a r€gistered tradémark nf
Copy.isht@ 1988, IntelCórpóration
Above iLBX
BTTBUS im
COMMputer ilfDDX
CREDIT iMMX
Daia PipeÌine Ìnsite i i r t è I B O S
i lntelevision
I2ICE nrieligEtrLldcltifier ICE inteligent Progrùmming
iCEL Intellec
iCS lrtellink
iDBP iOSP
iDIS iPDS
iPSB
ONCE PROMPT QUEST Qùex RM}V80 RUPI SLD UPI VLSiCEL
t Ì
MANUALS IN THIS VOLUME
This volume (Volume 2, Eúended iRlulp II User's cuides) contains the following
manuaÌs, all of which documeff the iRMX fI layers. These manual are intended to provide the information needed to use the iRMX II Opelating System.
Extenàed. iRMX@ II Nucleus User's Guiàe
Ertend?d |RMP II Ba\í. l/O Ststptk Uter's Guid"
Extehded. iRM1'@ II Extended I/O System User's Guíde Extended iR.tulX@ II Applicati.oh Loader Userb Guide Exiended íRMP Hurnan Intef.tce Userk Guide Extended íRMP II UDI User's Guíl.e
hfehded iRMl@ lIDevice Drivers User's Guide
'l'ne Ertended. íRM:@ Il Nucleus Useri Guil.e descdbes the concepts of the inoermosr layer, the Nucleus.
T'be E tehdzd. iRM7'@ II Basíc I/O System Userb Ga\da describes the concepts of the Basic I/O System.
îhe Exfended. iRivDP II Extend.ed. I/O System (Jserb Guidc descîibes rhe conceprs of rhe Exrended I/O system.
'fne ErtendEd \RAIP I Application Loadcr Ulerb Carrle describes hovy ro use the Loader to load your programs.
Tl'rc Exfehded ìRMX@ II Human I ktface User's Guide explains how to use and modify the Human Interface.
î'I\e Extendad, íRM)P II UDI User\ Guíd,e desri$es the use of all UDI, the language interface.
'lhe Extended LRMP 1I Device Drivers User's Guide describes the data sÍuctures and suDDort routines needed to write device drivers.
r-\
iRMX@ II User Guides Volume lu
YOLUME PREFACE
VOLUME CONTENTS
Manuals are listed in the order they appear in the volumes. For a synopsis of each manual, reîeî fo the Introductìon to the Extended ìRMX\ II Operatíng System.
VOLUME 1: Extendzd |RMP II Intrcù)ctiory Installatíon, and Operutíng Inttructíons Introdlctíon to the Ertended |RMX II Opetutíng System
Extended iRMX II Hardwue and SoÍf(,are Installation Guíde Operatork Guíde to the Extended |RMX II Hunan lnterface Ma^tter Index
VOLUME 2: Extended íRMX@ II Operutíng System User Guidas Exte d,ed .RMP II Nucleus Userk Guide
Ertended íRùIP II B.uíc I/O System User's Guide Extended íRMl@ II Extended I/O $stem Useî's Guide Extended íRMA@ Human Inteface User's Guide Extended, |RMX@ II Applicatíon Loader Userh Guíde
Extendad íRMX@ II Uhír'efial Development Interface User's Guidz Extended |RMX@ II Device Divers User's Guide
VOLUME 3: Extendad |RùIl@ II System Calls
Entended íRMX9 II M&leus Srstem Calls Reîerence Manutl Extended |RM)P II Basic I/O System Calb Refercnce Manual Extended |RMP II btend.ed.I/O System Calls Refermce Manual Extended íRM}@ I Applícatíon Loader System Call,s Refercnce Mahual Extendzd |RMP II Human Interface System Calk Reference Manual Extended |RM)P II UDI Swtem Calls Reference Manuel
VOLUME 4: Extended iRIutP II Opetutíng Esten Uîilities Extendcd. |RMP II Bootstrap Load.er Reference Manual Extended |RMP II System Debugget Refercnce Manual Ettended |RMP II Disk Veifcation Utílíty Reference Manual Extend,ed. |RMP II Progammíhg Techníques Reference Manual Guile to the Extehded íRMP II Inteructiye Confrguratíon Utitíty
VOLUI{E 5: Extended iRMXs II Inteqctíve Confguftitíon Utílíty Reference Exfended iRivlx@ II Interactive Confrguration Utiliry Reference Manual
iRMX@ II User Guides Volume
r-\ .
BEV, REVTSION HISTORY DATE
,001 Original Issue. 01/88
intet
{ì
E X T E N D E D i R M X @ I I
N U C L E U S U S E R ' S G U I D E
Inteì Corporation 3065 BowersAvenue Santa Ctara, California 95051
Copyright o 1988, Intel Corporation, All Rights Reserved
f
This manual documents the Extended iRMX II Nucleus subsystem. The material conîained in this manual is primadly intended for programmers who need to access system capabilities.
READER LEVEL
This manual is intended for programmers who are familìar with the mnc€pts c.ntained in the Introductíok to the Extended |RMX II Opemting SysteîL
RELATED PUBLICATIONS
The following manuals provide additional information that may be helpful to readers of this manual.
t |RMX 286 Networking Software Userb Guide, Order Number: 122323 . LAPX 286 UtíIíties User's Guíde, Order N\mber. 121934
. MULTIBUSd II Tmhsport Protocol Specífrcatbn, Order Number: 14927
Nucleus User's Gùide lll
CHAPTER OVERVIEW
CHAPTER 3
TASK MANAGEMENT
PAGE
PAGE
Nucleus Uset's Guide
CONTENTS
CHAPTER 4
EXCHANGE MANAGEMENT
CHAPTER 5
MEMORY MANAGEMENT
CHAPTER 6
OBJECT MANAGEMENT
PAGE
PAGE
PAGE
Nucleus Uset's Guide
CHAPTER 7
DESCRIPTOR MANAGEMENT
CONTENTS
PAGE
PAGE
CHAPTER 9
INTERRUPT MANAGEMENT CHAPTER 8
EXCEPTIONAL CONDITION MANAGEMENT
PAGE
Nucleus Useds Guide Yll
CONTENTS
9.4 TIANDLING SPURIOUS INTERRUPTS ...9-?2 9.4.1 Caling GEI$LEVEL... ...-.-.-.-...9-23 9.4.2 Judicious Selectioo oflnterruDt Levels ...-...-.-...9-23 9.4.3 Examining the In-service Register... ...,.,,.,.,..9-23
9.5 EXAMPLES OF INTERRUPT SERVICING...-.-...9-24 9.6 System Calls for Interrupte,...,.,.,.,... ...-.-...-.-9-n
CHAPTER IO
OPERATING SYSTEM EXTENSIONS PAGE
10.1 Introductiori.,... .-.-.-...-.-.-... 10-1 10.2 Thee Ways of Adding Functionality.... ...,...,...10-1 10.3 Creating an Operating System Extersion2
10.3.1 Proc€dures Used IÍ Operating System Extensions2 10.3.2 Interface ProceduresT
10.3.3 Bntry Procedures?
10.3.4 Function ProceduresS
10.3.5 RQ$ERROR And NUC$ERROR Procedures8
10.4 Establishing Exception-Handling Mechanisms... 10-11 10.5 Customized Exception Codes... ... 10-14
10.6 Linking the Procedures ... ... 10-14 10.7 Inclùding OS Efensions ... ... 10-14
10.8 Protecting Resources From Being Deleted... 10-15 10.9 System Calls For Extending The Operating System ...,... 10-15 CHAPTER 11
TYPE MANAGERS PAGE
vlll Nucleus Uset's Guide
CHAPTER 12
|RMX@ II MULTIBUS@ II SYSTEMS
CHAPTER 13
NUCLEUS CONFIGURATION
CONTENTS
PAGE 12.1 Introduction... ...,.,... PAGE12.1 12.2 Features of MULTIBUS@ II Systems. ...-.-...-..12-l 12,3 An Analory of How MULTIBUS@ II Systems lryork..,...,.,.,.,,,,.,...12,2 12.4 MUIITIBUS@ II Hardware Overview ,., ...,.,...-... 123
12.4. I Cenu al Scrvices Module (CSM)....,.... ,.,.,,,,...,,., j2-4 12.4.1.1 clobal Time-of-Day C1ock... 12-.i.global clock, MULTIBUS tI 12-5 12.4.2 Interconnect Address Space ,..., t2-.i.Intercomìect addr€ss spac€ 12-5 12.4.3 Bùilt-Ir SeUTests (BIST)...12-.i.Built-in SelfTests (BIST) 12-6 12.4.4 The MULTIBUS@ II Message Passirg Hardware and Messa ge ...-.-... 12-6 12.5 Extended iRMX@ II Software Overview. ,...,,,.2-j 12.5.1 The MULTIBUS@ II Transport Protocol.-.-.-.-.-.-.-.-...-...-.-.-.-. ....-...12-8
12.5.2 The Nucleus Communication Service. .,.,.,...12-8 12.5.3 Nucleus Communication Objects... ...-...I2-9 12.5.3.1 Port... ...12-9
12.5.3.2 BufferPools. ... 12-10
12.5.3.2.1 System Calls for Buffer Pools....,...,. ...,12-1I 12.5.3.2.2 Data Chaias... ,,.,.,..,.,.,..12-1I 12.5.3.2.3 Messag€ Fragmentation ... ...,,12-13 12.5.4 Systeú CaÌls to Work With MULîBUS@ II Message Space... ...12-13
12.5.4.1 System Calls for Interconrect Space. ...12-13 12.5.4.2 System Calls for Sending Messages through Message Space ,...12-13 12.5.4.3 Calls For Geîting lnformation About Message Passing
Agents (Boards)... ... 12-14 12,5,5 The Nucleus Communications Service System Calls...,... ...12-14 12.5,5,1 System calls used with buffer pool objects...,... -...-...12-14 12.5.5.3 System Calls Used to Send/Receive Messages Through ports... 12-15 12.5.5.4 System Calls ùsed v.ith the Interconriect Registers on a board...,.,.l2-16 12.5.6 Examples Using Nucleus Communications Service Calls ... .-...,...,...12-16
12.5.6.1 Interconnect Space Examp1e... ..,.,.,.,.,12-18 12.5.6.2 Creatir'gaPort for Message Sending and Receiving... ...,,,.,72-26
12.5.6.3 Sending Dara Ushg RQ$SEND$RSVP...12-31.
12.5.6.4 Sending a Data Chain Message...,.... ...1237 12.5.6.5 Sending a Message irr Fragments... ,,,,.,.,..,...12-44 12.5.6.6 Receiving a Mersage in Fragment Fo ...12-41 12.5.6.7 The Name Server Exarnple.,... ...,..,,,,,12-54 12.6 G1ossary.,... ,.,....,...12.56
Nucleus Uset's Guide tx
CONTENTS
APPENDIX A
EXTENDED iRMX@ II DATA TYPES APPENDIX B
OBJECT TYPES AND RESOURCE REQUIREMENTS
PAGE PAGE
APPENDIX C
EXCEPTION CODES PAGE
Figure 1-1. Initial Job Tree..., ... 1-4 Figure 3-1. Task State Transition Diagram... 3-4 Figuîe 5-1. Memory Movement Diagram ... 5-3 FiguÌe 9-1. lnterrupt Processi[g Mode...,... ...,.,.,.,.,..,9-12 Figure 9-2. 80286 Inteùùpt Lines ... 9-4 Figure 9-3. Flow ChaÍ of Interrupt Hand|ing...,...-... 9-15 Figure 9-4. Single-Buffer Intefupt Servicing ...,.,.,.,.,.,.,.,....,.,.,.,.. 9-17
Nucleus Usefs Guide
CONTENTS
FIGURES lcontinuedl
Figure 9-5. Multiple-Buffer Interrupt Servicing... 9-18 Figure 10-1. OS Ext€osions with Entry Procedure...,...,.,.,. 10-4
Figure 10-2. OS Extensioll without Entry Procedure ... 10-5 Figure 10-3. Sùúmary of Duties of Procedures in OS Extensions... 10,6 Figure 10-4. Handling Exceptions with an Exception Handler... 10-10 Figure 10-5. Control Flow for Handling Exceptions In-Line...-.-...-.-...-...-...-. 10-13 Figure 11-1. Creation Sequence for Composite Objects... 11-1 Figure 11-2. Type Manager Involvement in DELETE$JOB...,...11"4 Figure 1l-3. A Ring Buffer... -....,,--...----... 11-8 Figure 12-1. Simpffied MULTIBUS@ II Bus Architecture... 12-4 Frg'rre 12-2. A Simplified MULTIBUS@ II Message 12-7
Figure 12-3. A Data Chain Block and a Data Chainl2-12 Figll.re 12-4. Physical Location of Boards in the tsxampleslT Figure 12-5. Board Scanning AlgorithmlS
Figure 12-6. Implementation of a Boaad Scanner.,.,.,... ...,...12-25 Figure 12-8, Creating a Data Transport Protocol Port ... 12-30
Figure 12-9. An RSVP/REPLY Transaction between Two
Extended iRMX@ II Hosts... ...12-32 Figure 12-10. Algorithm for RO$SEND$RSVP ExampIe... 12-33 Figure 12-ll Algorithm for Server Board.... ...12-33 Frg]ùre 12-12. Client Board Code for RQ$SEND$RSVP ExampÌe ... 12-35 Figure 12-13. The Server Board Code to Receive and Answer
an RS\? Message... ...12-37
Fig].tre 12-14. Data Chain Send ... ... 12-40
Figure 12-15. Receive a Message in Data Chain Form...12-44 Figure l2-16. Send a Message iri F agments... 12-47 Figúe 12-1'7. Receive a Message in Fragments... 12-50
Figure 12-18. Sending a Message that Requir€s
Receive Fragírentation...,...,.,... ...12-52
Figure 12-19. Literal File DCOM.LIT...12-53 Frg.re 12-20. External File DCOM.EXT...12-54
Nucleus Use/s cuide xÌ
INTRODUCTION
The Exended iRMX@ II Nucleus is the core of every iRMX II application system. Its activities include
r Supplying scheduling functions
. Controlling access to system resources
o Providing for communication between processes and processors . Enabling the system to .espond to extemal events
The Nucleus provides the building blocks from which the other subsystems (Basic I/O SysteÍ! Extended I/O System, AppÌication Loader, ard Human Intedace) and application systems are constructed. These building blocks are called q$gqqq and are classified into the following caregories called qEigELl@e!:
. Tasks r Jobs . Segments . Mailboxes . Semaphores . Regions
o Extension objects . Composite objeats
The îollowing generalizations can be made about these qpes:
. Tasks are the active objects in a system. They do the work of the system.
. Jobs are the environments in which tasks do their work. An envionment consists of tasks, the objects that tasks use, a dfectory where tasks can catalog objects so as to make them available to other tasks, and a memory pool.
. Segments are pieces of Ínemory, the medium that tasks use for communicating and for storing data.
e Mailboxes are objects to which tasks go to send or receive other objects.
Nucleus Usefs Guide l-l
O!'ERVIEW
. Semaphores are the objects that enable tasks to synchronize their actions with other tasks.
. Regions are objects that guard a specific collection of sha.ed data.
. Extension objects a.e objects which designate new q?es of objects.
. Composite objects objects of the new q?es designated by extension objects.
The Nucleus does extensive record-keeping of objects. It keeps track of each object by means of a 16-bit value called a lqkqo The Nucleus provides a flumber of operators, called ry$glqlallq that tasks use to manipulate objects.
When usfurg a system call, a task supplies parameter values, such as tokeng names, or other values, dependiog oo the reqùirements of the system call, Some of the functions that tasks can perform with system calls are
. Create objects . DeÌete objects
. Send úessages to other tasks . Receive messages from other tasks . Obtain infomation aboùt objects . Caîalog objects with descriptive names . Delete objects from catalogs
1.2 OBJECTS
Each of the object t,?es discussed in this manual has unique characteristics. These characteristics are discussed in detail in the following sections.
1.2.1 Tasks
!5$ do the work of the system. They car be considered a virtual CPU. Tasks used by the iRMX II Operating System are software tasks. They should not be confused with 80286 processor hardware tasks. The entire iRMX II Operating System and its tasks, when operatifig without exceptions, are one hardware task. A task has two goals:
. Its primary goal is to do a specific piece ofwork.
. Its secondary goal is to obtain control of the processor so that it can progress toward its primary goal.
l-2 Nucleus Uset's Guide
OI'ERVIEW
OrÌe of the main activities of the Nucleus is to arbitrate when several tasks each want control over the p.ocessor. The Nucleus does this by maintaining an execution state and a priority for each task. The execution state for each task is, at any givcn time, either running, ready, asleep, suspended, or asleep-suspended. The priority for each task is an Dteger value between 0 and 255, inclusive, with 0 being the highest priority.
The arbitration algorithm that the Nucleus uses is thaî the rùnning task is the ready task with the highest (numerically lowest) priority.
As viewed by the Nucleus, a task is merely a set of values, some of which aîe r The task's priority
. The task's execution state
. A token for thejob that contains the task
Whcn a task becomes the running task, the following events occur, in order:
1. The context of the previously running task is saved by the Nùcleùs.
2. The Nucleus loads the new running task's context.
3. The new task bcgins executing.
The task continues to run until one ofthe following events occurs:
. The task removes itself from the ready state. For example, the task can suspeùd or delete itself; thc task can attempt to receive a token for an object that has not yet been sent, in rvhich case it might elect to wait (in the asleep state),
. The task (task A) is pre-empted when a higher priority task (task B) becomes ready.
For example, task B might previously have gone into the asleep state for a specific period of time. When the time period has passed, rask B becomes ready again.
Because it is then the highest priority ready tasb rask B becomes the running task.
. The task is rescheduled due to round-robin. For a comDlete exDlanation of round- robin scheduling, see Chapter 3.
't.2.2 Jobs
A jeb consists of tasks and the resources they need.
The jobs in a system form a family tree, with each job, except the root job, obtaining its resources from its parent. The tasks in the ùser jobs can create additional objccts. If they create additionaljobs, this enlaÌges thejob tree.
Thejob tree, as it may look after the initialization of a system, is shom in Figure 1-1.
Nucleus Uset's Guiile 1-3
OVERVIEW
Figurc 1-1, Initial Job Tree
Associated with each job is an qUigqllircO@ry. Objects are known to the Nucleus by their respective tokens, but often, in the code that is executed by tasks, the objects are known by symbolic names. The object dùectory for a job is a place in memory where a task can catalog ari object under a name. Other tasks tbat know the ùame can then use the directory to access the object.
Also associated with each job is a memorv pool. This is al amount of memory up to 16M bytes, which is allocated to the job and its descendants. All memory needed to create objects in îhe job comes from the memory pool.
l-4 Nucleus Uset's Guide
O}'ERVIEW
1.2.3 SegmènÈ
A fundamental resource that task need is memory. Memory is allocated to tasks in the form of segments which are addreósable, contiguous blocks of memory containing up to 64K bytes of either code or data. A task needing memory requests a segment of $/hatever size it lequires. The Nudeus aîtempts to create a segment from the memory pool given to the task's job wheri îhejob was created. \ryh ethe segment is being used by the task, the 80286 microprocessor che.ks îhe segment lengrh to ensure that the segme[t does not read or write beyond the segment length defined. If there is not enough memory available, the Nucleùs will try to bo.row the needed memory from ancestors of the job. In this respect, the tree-structured hierarchy ofjobs is instrumental in resource distribution.
1 .2.4 Buffer Pools
Buffer pools are holding areas for segDents, you creaîe a buffer pool and then filI it.with buffers using the RQ$CREATE$SEGMENT system call. Having a pool of memory readily available cuts down on system overhead because allocating existing buffers is faster than creating and deleling segments.
1 .2.5 Exchange Obiects
Thee of the object types are used as information exchanges: mailboxes, semaphofes, and regions. Each of these is explained in the following sectioris.
1.2.5.1 Mailboxes
A lqq[bgÈ is one of three types of objects îhat can be used for intertask communication.
\ryhen task A \ì/ants to sefld an object or a data packet to task B, task A must seod a token for the object or the actual message to a úailbox, and task B must visit that mailbox. If a tokel or a data packet isn't there, task B has the option of waiting for any deshed length of time, If a token is being sent, task B can access the object after obtairdng the token.
Sending a token for an object in this manner can achieve various puryoses. The object might be a segnent that contains data needed by the waiting task. On îhe other hand, the segment rnight be blank, and sending its token might constitute a signal to the waiting task.
1.2.5.2 Semaphores
A semaphore is a custodian of abstract "units." It dispenses units to tasks that request them, and it accepts units from tasks. Units at a semaphore behave like null messages at a maiÌbox.
Nucleus Uset's Guide 1-5
OVERVIEW
An example of Spical semaphore use is mutual exclusion. Suppose your application system contains one I/O device which is being used {or output by multiple tasks. To ensure that only one of these tasks can use the device at a given time, you can establish a semaphore which has one unit and requfue that tasks obtain the unit before using the device. A task wanting to use the device would request the unit from the semaphore.
when it gets the unit, it can use the device and then retum the unit to the semaphor€.
Because the semaphore has no units while the task is using the device, other tasks are effectively excluded from using the device. Yoù might want to think of units at a semaphore like currency at a bank. If there is no money in the bank, the bank cannot function.
1.2.5.3 Règions
A lggigu is a one-unit semaphore with special semantics. It is an iRMX II object that tasks can use to restrict access to a specific collection of shared data. once a task gains access to shared data through a region, by issuing a successful ACCEPT$CONTROL system call, the task can not be suspended or deleted (although it may sril be pre-empt€d by a higher priority task) by other tasks until it surrenders access. When the task
currently using the shared data no longer needs access, it notifies the operating system, which then allows the next task to access the shared data.
1.2.6 Extension And Composite Objects
Whenever more than onejob in your applícation system requires a function not supplied by the iRMX II Operating System, you can add new tlpes ofobjects to your system to provide the needed function. The procedures that support these added functions are called operating system extensions. A type manager is an operating system extension that can create objects of a new tlpe. A given t)?e manager can only create one tlpe of object, but can create numerous objects (called composite objects) ofthat object q?e. The object type is desìgrìated by an object called an extension object.
1.3 DESCRIPTORS
The Nucleùs keeps track of each object by means of a 16-bit value called a tokeÍ. The token contains the logical address of the object. However, a d€leLiELoI is needed to determine the physical address. Descriptors are used to give an area of memory
addressability. Each descriptor is an entry in a descriptor table and contains the physical address of a segme[t. The operatiog syst€m assigns each object a descriptor when it is created. Every object must have at least one descrìptor or there is no way to address it.
1-6 Nucleus Usefs Guide
OT'ERVIEW
.1.3,1 DescriDtor Tables
AII descriptors reside in a hardware descriptor table. 1lìcrc arc thrcc typcs of dcscriptor tables: the clobal Descriptor Table (cDT), the Local Descriptor Table (LDT), and the Interrupt Descriptor Table (IDT).
1.3,1.1 Global Descriptor Table (GDT)
The GDT is a table of up to 8K entries each of which is a descriptor containing the A-bit physical address used by the sysîem to acce.ss areas oi memory. Desoiptors in the cDT can be used by every task in the system. There is only one GDT for the entire operating s,$tem. All the descriprors you need vr'ill be in rhe GDT.
f.3.1.2 Local Descriptor Table (LDT)
The LDT is the only hardware LDT in the iRMX II Operating System. It is reserved for system use. Additional lDTs are not available.
'1.3.1.3 Interrupt Descripîof Tabte (tDT)
The IDT is a table containing the address of the intermpt handling code to be executed when an interrupt occurs, Addresses can be entered into the IDT either when the system is created or dynamically using the SET$INTERRUPT system call.
I .3.2 Call-Gates
Call-gates are used to enter the iRMX II Operating System and OS e{tensions. they redirect flow within a task from one code segment to another. Each system call uses a call-gate to traùsfer the progam directly to the iRMX service roùti[e requested. Call- gates are part of the descriptor tables and are reselved when the system is configured.
1 . 4 H A N D L E R S
Two kinds of events can be handled specially: exceptional conditiom and inte.rupts. The remainder of this chapter describes the handlers for these events.
Nucleùs Useros Guide
OVERITEW
1 .4.1 Exception Handlers
Tasks occasionally make errors, If an error occurs during an iRMX II system call, it causes an exceDtional condition. If an error occurs as a result of a haîdware protection feature, such as, a program tryil€ to execute out of its segment bourids or trying to execute a segment that is defined zrs read only, it causes an exceptional condition known as a trap. The occurrence of an exceptional condition or a trap can, if desired, cause a transfer of control to the exception handler associated with the current task. the exception handler is a procedure that typically deals rì/ith the problem by one of the following methods:
. Correcting the cause of the problem and trying again . Deleîiog or suspending the task that caused the error
The designer ofan iRMx Il-based system has two kinds of de.isions to make when establishing an exception handler for each task. The first decision concerns the choic€ of exc€ption hafldlers. The task can have its own custom exception handler, it can use the exception handler lor the job to which it belongs, or it can use the Intel-provided system exception handler, The second decision concerns vr'hen cortrol goes to an exception handler. The task can direct control to the exception handler in avoidable (programmer) and/or unavoidable (environmental) conditions. If control is not directed to an exception handler, the task must handle the exception.
1 .4.2 lnterrupt Handlers
To function effectively as a real-time system, an iRMX II application system must be responsive to external events. An i!!!!ruplh4!!!le!. which is required for each source of external events (interrupts), is a procedu.e that is invoked by hardware to respond to an as).nchronous event. The handler takes control immediately and services the interrupt.
When the interrupt handler is finished servicing the interrupt, it suúenders the processor, which returns îo the inter.upted procedure.
As part of its seflicing, the inteîrupt handler can invoke a task îo further process the interrùpt. An interrupt handler invokes an interrupt task if the processing of an interrupt requires large amounts of time or if the processing rcquires those Nudeus system calls that interrupt handlers are prohibited from using.
1-8 Nucleus Usefs Guide
2.1 INTRODUCTION
A job is an environment in which iRMX II objects such as tasks, mailboxes, semaphores, segments, and (offspring) jobs reside. In additiori, ajob has an object dftectory and a memory pool of up to 16M bytes. The job's memory pool provides the mw material irom which obje.ts can be created by the tasks in the job.
Applications consist of one or more jobs. Jobs are independent but they may share resouces. Each job has its own tasks and may have its own object directory. Objects may be shared between jobs, although each object is contained in only one job.
The programmer rnust decide whether tasks belong in the same job. In general, you should place tasks in the same job if
. They have similar or related purposes . They share many resources
. 'lhey have similar lifespans
2.2 JOB TREE AND RESOURCE SHARING
The jobs in a system are arranged in the form of a tr€e. The root job is plovided by the Nucleus. The remainingjobs, includingjobs that are created dynamically while the sysrem runs, are descendaùts of the rootjob. A job containing tasks thaî create otherjobs is a p31941g job. A newly created job is a child of the job whose rask created it.
Associated v/ith each job is the following set of limits:
o Maximum size oî its object directory
. Mavimum and minimum sizes of its memory pool
. Maximùm number of simultaneously existing objects that it can contain r Maximum number of simultaneously existing tasks that it can contain . Highest priority of any îask contained ill it
You must speciry these limits whenever you create a job. These lilnits, vrith the exception of objert directory size, apply collectively to the job and all of its descendart jobs.
Nùcleùs Useis Guide
JOB À?LÀN,{GEMENT
For example, ifjobA createsjob B, these events occur:
. Sùfficient memory to meet job B's minimum mernory pool requiements is îransfeded from job A's meùory pool to that ofjob B.
. The memory forjob B including its object directory is taken ftom job A's memory
pool.
. The numbers of tasks and total objects thatjob A can coÍtain are reduced by the corresponding valùes spe.fied for job B.
r The specified maximum priority for tasks in job B cannot exceed the maximum pdority for tasks in job A.
ffjob B is later deleted, its resoùrces are returned to job A.
2.3 JOB CREATION
A job is created with one îask whose fùnctions should include doing some initializing activities for the newjob. Initializing activities can include housekeeping and qeating other objects h the new job.
When a task qeates a job, it has lhe option of passing a tokeD for a p4É!f9l9!_sqjgq to the newly created job. The parameter object can be of any t ?e and can be used for any purpose. For example, the parameter object might be a segment containing data,
arranged in a predefined format, needed by tasks in the newjob. Tasks in the newjob can obtain a token for the job's paiameter object by meaN of the GET$TA.SK$TOKENS system call, desc.ibed llntheíRMX II Nucleus Sltstem Calls Reference Mantml-
2.4 JOB DELETION
Before a job can be deleted, all of its extension objects (see Chapter 1 1) and descendant jobs must be delel.cd. By using lhe RQE$OFFSPRING system call, thc deleting task can probe down the job tree and find all of the descendants. Then it can delete them,
beginning with descendants that have no children and working up the tree. Alter all of thc descendants have been deleted, the îask can delete the target job.
2.5 SYSTEM CALLS FORJOBS
The following system calls manipulate j obs:
. RQE$CREATE$JOB-creates a job with a memory pool of up to 16M bltes and returns a token for the job; resources for the new job are drawn fiom the resources of the job to which the invoking task belongs. This system call should be used ior all new applications or for present applications which may expand beyond 1M blte.
Nucleus Uset's Guide
JOB MANAGEMENT
. CREATE$JOB-qeates a job with a memory pool of up to 1M b].te and retums a token for the job; resources for the new job are drawn from the resources of the job to which the invoking task belongs. This call is available for compatibility v/irh the iRMX 86 Operating System. It should be used only by applications that requfue compatibitity with the iRMX 86 Operating System. All new applications shoùld use
RQE$CREATE$JOB.
. DELETE$JOB--deleter a childlessjob that contains no extension objects and returns the job's resouces to its parent.
r RQE$OFFSPRING-provides a list ofthe childjobs of the specifiedjob in a useÌ- sùpplied data structure.
. OFFSPRING-provide.s a segÌnent c.otaining tokens ofthe child jobs of the specified job.
For a complete list and explanation of the iRMX lI Nucleus system ca)ls, see the Erfended îRMX II Nuclew System Calb Merence Manual.
Nucleus Uset's Guide
3.1 INTRODUCTION
Tasks are the active objects in an iRMX lI system. Each task is part of a job and is restricted to the resources that its job provides.
The iRMX II Nucleus maintains a set of attributes ior each task. Among these attributes are the priority and execution state of the task.
3,2 PRIORITY
A task's pdodty is an integer value between 0 and 255, inclusive. The lower the priority number, the higher the pdority of the task. A high priority task has favored status as it competes with other îasks for the microprocessor.
Unless a task is involved in processing interrupts (see Chapter 9), its priority should be between 128 and 255. when a task having a priority in the range 0 to 122 is running, cefain external inîerrupt levels are disabled, depending on the pdority.
3.3 TASKSTATES
A task is always in one of five erecution states. The states are asleep, suspended, asleep- suspended, ready, and Ìunning.
3.3.1 The Asleep State
A task is in Lhe asleep state when it is waiting for a request to be granted. A task can put itself in the asleep state by issuing a SLEEP system call, or it can be placed there by the operating systcm after issuing a request that cannot be granted immediately if the task is willing to wait. In either casg the length of time the task stays in the asleep state is conîrolled by a parameter that the task speeifies.
Nucleus Uset's Cuide 3.1
TASK MA.NA.GEMENT
3.3.2 The Suspended State
A task ente.s the suspended state when it is placed there by another taslq when it is waiting fo. an interrupt, or when it suspends itself. Associated with each task is a suspension depth, which rcflects the number of "suspeùds" outstanding against it, Each suspend operation must be coùntered with a resume opemtion befote the task caiÌ leave the suspeùded state. The suspension level (the number of outstanding suspends) is not
available as a service of the operating system.
3.3.3 The Asleep-Suspended State
When a slceping task is suspended, it entels the asleep-suspended state. In effect, it is then in both the asleep and suspended states. While asleep-suspended, the îask's sleepiog time might expfue, putting it in the sÌrspended state. Aso, if atother task resumes an asleep-suspended task, the latter task will enter the asleep state.
3.3.4 The Ready and Running States
A task is ready if it is not asleep, suspeÍded, or asleep-suspended. For a task to become the running (executing) task, it must be the highest priority task in the Ìeady state,
3.4 TASK STATE TRANSITION
The Nucleus allocates processor tine to tasks in a priority-based manner. The following discussion explains this method of allocating processor time.
As an iRMX II application system runs, eve[ts occùr which cause tasks to pass from state to state. The iRMX 1I Ope.ating System is, therefore, event-driven. Figure 3-1 shows the paths of transition between states.
'fhe îofowing list describes, by number, the events that cause the tmnsitions in Figure 3-1.
In this list, the migating task is called "the task":
(1) When the task is created, it is placed in the ready state.
(2) The task goes from the ready state to the running state when one of the following o@urs:
. The task has just become ready and has higher priority than any other ready task.
. The task is ready and no other task of equal or higher priority is before it in the ready queue (see section, "Round-Robin Scheduling," for further explanation).
(3) The task goes from the mnning state to the ready state when the task is pre-empted by a higher priority task that has just become ready or when the task is reschedùled as a result of round-robin (see section "Round-Robin Scheduling'').
Nucleus Uset's Guide
TASK MANAGEMENT
(4) The task goes from the running state to the asleep state when one ol the following occurs:
. The task puts itself to sleep (by the SLEEP system call).
. The task makes a request (for example, by issuing a RECEIVE$MESSAGE, RECEM$UNITS, or LOOKUP$OBJECT system call) that cannot be ganted immediately and expresses, in the request, its willingness to wait,
(5) The task goes frorn the asleep state to the ready state or from the asleep-susp€nded state to the suspended staîe when one of the following occurs:
r The time period specified in the invocation of the SLEEP system call expires.
. The task's designated waiting period expires without its request being granted.
. The task's .eqùest is granted (because another task issued a systcm call such as SEND$MESSAGE or SENrD$UNI'IS that sends a message, and the message was received).
. The object at which the task was waiting was deleted (for example, mailbox).
(6) The task goes from the running state to the suspended statewhen the task suspends itseff (by the SUSPEND$TASK or WAIT$INTERRUPT sysrem call).
(7) The task goes from the ready state to the suspended state or from the asleep state to the asleep-susperÌded srate when the task is suspended by another task (by the SUSPENDSTASK system call).
(8) The task remains in the suspended state or the asleep-suspended state when one of the following occurs:
. The task is suspended by another task (by the SUSPEND$TASK system call).
. The task has a suspension depth greater than one and the task is resumed by another îask (by the RESUME$TASK sysrem call).
(9) The task goes from the suspended state to the ready state or from the asleep- suspended state to the aslecp statowhen the task has a suspension depth olone and the task is resumed by another task (by the RESUME$TASK system ca[).
(10) The task goes from any state to non-existence when it is deleted (by the DELETE$TASK DELETE$JOB, or RESET$INTERRUPT system call).
Nucleus Userrs Guide 3-3
TASK MA.NAGEMENT
,1
(s)
\7)
lÍffiffiffl|.*'
R U N N I N G ( 6 ) S U S P E N D E D (8)l 7 )
A S L I E P . S U S P E N O € O
FiguÌe 3.1. Task State Transition Diagram
3.5 ROUND-ROBIN SCHEDULING
As mentioned previously, the iRMX II Operating System schedule.s tasks based on
priority. Two tasks with the same priority compete for CPU resources, arid often one îask is left waiting indefinitely. To p.event this from happening, the iRMX II Operating System offers round-robin scheduling.
Round-robin scheduling is particularly desirable in a multi-user development
envftonment. It prevents one task irom monopolizing the CPU while other tasks wait indefinitely.
There are a number of facto$ which can cause a task to lose conhol of the CPU.
. The task is pre-empted by a hardware inîerrupt.
3-4 Nucleus User's Guide
TASK MANAGEMENT
. The task is pre-empted by a higher priority task.
. Thc task p€rforms a system call that causes it to relinquish control of the CPU.
In the filst two cases, the task (relerred to throughout the text as task A) remains ir the READY state. Without round-robin scheduling when the higher priority activity is completed, task A regains control. Thus, any other tasks having the same priority as task A will not run uritil task A performs a system call causing it to relinquish control of the CPU.
With roùnd-robfur scheduling, task A is allocated a time quota. wh€n its time quota expireq it is pre-empted- If there are other tasks ofthe same priority in the READY statg task A loses control of the CPU to another tas( and is placed in the ready list after all tasks of the same pdority. Task A regains c.ntrol orúy when it reaches the top of the list.
Round-robir schedulirB aflepts only tasks that are of lower p.iority (numerically higher) than a level you determine when configuring the system. The recoÍìmended threshold priority level of 140 ensur€s that high-priority, time-critical tasks such as interrupt tasks are not affected. The Nucleus always executes the highest priority task until it is p.e- empted by a higher priority ready task or ùntil it relinquishes control.
The following example illustrates the advantage of using round-robin scheduling. Assume you have tasks A, B, and C. Task C has priority 130, and tasks A and B have priority 200.
Round.robin scheduling has been configured with a time quota of 5 ticks and a threshold priority of 140. Task A runs for 2 clock ticks when task C becomes ready. Task C
immediately gains control because of its higher priority. when task C relinquishes control of the CPU, task A continues to run for its remaining 3 clock ticks. It is then pre-empted and task B runs. After task B relinquishqs control or is cornpleted, task A is rescheduled for another 5 clock ticks. Without round-.obin scheduling, rask B would not run as task A would continue running until a higher pdority task became ready or it relinquished the processor.
To implement round-robin scheduìing it is necessary to configure two parameten on the
"Nucleus" screen of the Interactive Configuration Utility, These parameters establish the threshold priority level afld the time quota each task can run before it is pre-empted. The default threshold priority is 255, which means round-robin is turned off. To use round- robin, the recommended threshold priority is 140. The default time quota is 50
milliseconds. For more details on configuring the Nucleus, see the .RMX II Interactive Cokigurudon Utîliry Relercnce Manwil.
Nndeùs Uset's Guide
TASK MANA.GEMENT
3.6 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
4.5 RISKS INVOLVED IN SHARING DATA
Occasionally, several tasks in a sjrstem mùst share data. If the tasks run concurrently and the data is subject îo change, access to the data must be restricted to one task at a time.
The followirg €xample illustrates the importance of controlling task access to data.
Suppose tasks A and B are both part of an air-traffrc-control applìcation system. Task A runs at fixed time intervals and checks for any potential collisions. Task B runs as a result of an hterrupt caused whenever the sweep of the radar detects an airoaft. Task B is of higher priority than task A and is responsible for updatirig the position of the detected aircraft. Potentially, task B could corrupt the data used by task A, For instancg suppose that task A is in the procers of extrapolating the positíon of a particular aircraft. It first fetches the craft's last-reported position and uses the craft's velocity to estimate the position at some time in the near future. While task A fetches the X-coordinate of the position it is pre-empted by task B before it can fetch the Y- aùd z- coordinates. Task B now updates the craft's X-, Y-, and Z-coordinates to reflect the fresh information gathered from îhe radar. Task B suffenderc the processor, and the system resumes ruoning task A. Task A finishes fetching the craft's last-reported position but ends up with cormpt information. Instead of using (old )i old Y, old Z) or (new X, new Y, new Z), task A believes the last reported position to be (old )4, new Y, new Z). In this application, this error could lead to disaster.
Corruption of data can occur in this manner whenever the following îhree conditions are met:
. The data is shared between two or more tasks.
r The tasks sharing the data run concurrertly. (That is, one of the tasks could possibly Pae-empt another.)
. At least ooe of the tasks changes the data,
Whenever all three of these conditions exist, you must take special precautions to prctect the validiîy of the shared data. You must ensure that only one task has acce-ss to the shared data at any instarlî, a.ld you must ensure that the task having access cannot be pre- empted by other tasks desiring accers. This protocol for sharing data is called ouEal exclusion.
4.6 MUTUAL EXCLUSION USING SEMAPHORES
Tasks can use semaphores to obtain mutùal exdusion. However, ùsing semaphores fo!
this purpos€ can lcad to two kinds of problems:
r Priority Botdenecks
Sùppose that three tasks, A, B and C, have low, medium and high priority,
respectively. lf these tasks employ a priorily-queued semaphore to ensure that llo
4-6 Nucleùs Usefs Guide
EXCIIANGE MANAGEMENT
more than one of them uses shared data at any ifistant, the following situation could arise:
Task A (low priority) obtains access to the data ard continùes to îun, Task C (high priority) atterrpts to gain access, but is forced to wait at the semaphore until task A frees the data.
Task B (mediurn priority) avrakens from a timed sleep and pre-empts task A (low priority).
In Step Z task C must wait for task A (which has lower priodty) to finish usirg the shared data, since task A gained access to the data before task C. This kind of delay is inherent in mutua.l exclusion.
In Step 3, however, the delay is unreasonable. Task C is foîced to wait for task B (which has lower priority than task C) ever if task B does not use the shared oaÉ.
r Tying Up ìhe Shared Data
If several tasks use a somaphore to gover[ access to sharcd data, and the task currently havirg access is suspended, the semaphore prevents ariy other tasks from using the shared data. Only after the sùspended task is resumed can it free the shared data for ùse by the other tasks.
li the task using îhe data is deleted, rather than merely b€ing suspended, the situation is even worse. lhe governing semaphore ptevents any other tasks from ever using the shared data.
i You can eliminate both of these kinds of problems by using regions rather than i semaphores to govem the sharing ofdata.
4.7 MUTUAL EXCLUSION USING REGIONS
Tasks can ùse regions as well as semaphores to obtain mùtua1 exclusion. However, you should tote these facts about regions:
r The priority of the task that currently has access to the shared data may temporadly be raised. This happens automatically (at regions where the task queue is priority- based) whenever the task at the head of the queue has a priority hígher thar that of the task that has access. Under such circumstances, the priority of the task having access is raised to match that of the task at the head of the queue. When the task having access surleflders ac{ess, its priority automatically reverts to its original value.
This priority adjustment prevents the pdoÌity botdeneck that can occur when tasks use semaphores to obtain mutual exdusion.
. Once a task gains access to shared data through a region, the task can not be suspended or deleted (although it many still be pre-empted) by other îasks until it surre[ders access. This charactedstic prevents îasks from îying up shared data.
t.
2.
3.
Nucleus Usels Guide 4-7
EXCHANGE MANAGEMENT
CAUTION
When a lask gains access through a region, it must not attempt to suspend or delete ltsell. Any attempt to do so wí tock up th€
region, prev€ntin9 other iasks from accessing the data guarded by the region. In addition, the task will nèvér run again and its memory will not be returned to lhe memory pool. Also, it the task in the region attempts to delete itself, all other tasks that tater attempt to delete themselves will encounterthe same memory pool problèms, You should avoid using regions In Human lnterface applications. It a task In a Human Interfacè applicallon uses regions, the appllcation cannot be stopped asynchronously (via CONTROL-C entered at a terminal) while the task ls accessing data guarded by the region.
. When you create a region you must speciry which of r.Ío rules (FIFO or priority) is to be used to determine which waiting task next gains access to the shared data.
4,8 USEFULNESS OF SEMAPHORES
Despite the seeming drawbacks of semaphores, there are three reasons to use them:
1. You can use semaphores to accomplish much more than mutual exclusion. For example, with semaphore* you can slmchronize multiple tasks or allocate resources.
Regions, on îhe other hand, provide or y nìutual exclusion.
2. Because of the possibility of deadlock, regions should not be ùsed outside of extensions to the operatillg system. Consequently, programmers not famíLiar with operating system extensions must use semaphores to accomplish mùtual exclusiori.
3. Semaphores allow a task to set an upper limit on the amoùnt of time the task is willing to wait for access. In contîast, regions provide no such option. Tasks using regions for mutual exclusion have or y two choices:
. They can request immediate access (with the ACCEI'I$CoNTROI- system call). If a task make6 such a reqùest and access is not available immediatelf the task does flot wait at the region. Rather, it receives afi exception code and continues to run.
. They càn request access as it becomes available ({.ith the
RECEM$CONTROL system call). This kind of request causes the task to wait at the region until access becomes available. If access never bemmes available, the task riever runs again.
4-8 Nucleus Uset's Guide
EXCHANGE MANAGEMENT
4.9 REGIONS AND DEADLOCK
A major concern in any multitasking system is avoiding deadlock. Deadlock occurs whcn one or more tasks permanendy lock each other out of required resources. The following h)?othetical situation illustrates how deadlock can occur in using nested regions and how to avoid this situation.
NOTE
In the following example, the only system call used to gain access is the RECEI!'E$CONTROL system call. Tasks usiíg rhe
ACCEPT$COMROL system call cannot possibly deadlock at a region uíless they keep trying endlessly to accept control.
Suppose that two tasks, A (high priority) and B (low priority), both need access to trvo collections of shared data, called Set 1 and Set 2. Access to each set is goverled by a region (Region 1 and Regior 2).
Now sùppose that the following evelts take place in the order listed:
1. Task B requests access to Set 1 via Region 1. Access is granted.
2. Before task B can request access to Set 2, an interrupt occurs and task A pre-empts task B.
3. Task A reqùests access to Set 2 via Region 2. Access is granted.
4. Task A requests access to Set 1 via Region 1. Task A must wait becaùse task B akeady has access.
5. Task B resumes running and requests access to Set 2 via Region 2. Task B must wait because task A already has access.
At this point task A is waiting for task B ard vice veîsa. Tasks A afld B are hopelessly deadlocked, and any other tasks that request access to either set of data will also become deadlockcd.
This team deadlock situation applies only to systems in which regions are nested. If your system must use nested regions, yoù can prevent team deadlock by adhering to the following rule:
Apply a stdct ordering to all the regioris in your system, and code tasks so that they gain access according to the ordcr. For cxamplc, supposc that your systcm uscs 12 regions. Write the names of the regions on a piece of paper in any order, and number them starti.g rii'ith 1 As yoÙ program a task that nests any of the regions (say Regions 3, 8, and 10), be sure that the task requests access in numerical order and relinquishes the regions in reverse numerical order. The essential element of this technique is that
Nucleus Userls Guide 4-9
