Download Software for the 6809 Microprocessor board - Indico

Transcript
Software fox the 6809 Microprocessor board
Field
SEMTYP
SEMVAL
NXTSEM
SEMOWNER
SEMOLNK
Offset
0
1
2
4
6
Size
1
1
2
2
2
C. Verkerk and A.J. Wetherilt
Description
Semaphore type
Semaphore value
Link to list of threads waiting on this sema
Current semaphore owner
Link to list of owner's semaphores
Table 2.7: Semaphore structure definitions
as messages, signals and the default device drivers and are created during
system initialisation. The remainder are ava.ila.ble for use by an application
program. Alternatively, RInOS also allows the creation of dynamic or user
semaphores using memory owned by the application. In this ease the application creates the semaphore structure given in Table 2.7, page 32 and uses
a pointer to this structure when performing operations on the semaphore.
The structure is common to both types of semaphore; the difference between
the two types being that system semaphores all ha,ve space reserved during system initialisation and are identified by a unique number whereas user
semaphores are created by the application and are identified by their address.
During semaphore creation (for both system and user types) the fields
of the semaphore structure a.re filled in with appropriate values. The system call OSCreateSem performs this task for system semaphores and returns
the semaphore identification number. For user semaphores, the application
program must perform this task. The type of the semaphore is defined by
placing the desired value from Table 2.8, page 33, into the SEMTYP field of
the semaphore. It can be seen in this table that several options are available
for Event semaphores. The simple Event behaves in an identical manner to
a Mutcx except that it wakes all processes waiting on it and sets its value
to 1. This is sometimes not the desired action: In some cases it is necessary to wake only those processes that are waiting on the semaphore when
the particular event occurs. If a process docs a DOWN on a simple Event
semaphore after the event has taken place, it will not be blocked but will
continue. In repetitive events, this type of semaphore after its first trigger
will always indicate the occurrence of the event when what is required is the
occurrence of each individual trigger. To circumvent such problems, RInOS
also uses the Resettable Event semaphore which instead of incrementing its
value to one following the event trigger, always keeps the value of zero. In
this way when a process waits for the next event in a repetitive sequence,
the occurrence of a previous event does not affect whether or not it blocks.
Somewhat more rarely encountered but nonetheless of use, is the situation
Workshop on Distributed Laboratory Instrumentation Systems.
Abdus Salam ICTP, Trieste November 26 - December 21, 2001,
32