
CHAPTER 5 SYNCHRONOUS COMMUNICATION MANAGEMENT
User’s Manual U14833EJ2V0UM
47
5.2.2
Deleting semaphores
A semaphore is deleted by issuing the del_sem service call. In other words, once del_sem is issued, the kernel
invalidates the specified semaphore control block and puts the target semaphore in the non-existent state.
Even if a task exists that has acquired a resource for the deleted semaphore, that semaphore will still be deleted.
In this case, all the waiting tasks are released from the waiting state and the error code E_DLT indicating that the
semaphore has been deleted is returned as the return value of the service calls wai_sem and twai_sem. Note,
however, that tasks that have already acquired a semaphore will not be notified of that semaphore’s deletion.
After a semaphore is deleted, a semaphore with the same ID number as the deleted semaphore can be newly
created.
5.2.3
Acquiring resources
Resources are acquired from semaphores by issuing one of the service calls wai_sem, twai_sem, or pol_sem.
If there is a request to acquire a resource, the kernel checks the value of the resource counter of the target
semaphore and assigns the resource to the task if the counter is 1 or higher (decrementing the counter by 1), or
carries out the processing corresponding to the issued service call if the counter is 0. In other words, a task is put in
the resource acquisition waiting state by the service calls wai_sem and twai_sem, and waits until the resource has
been acquired, in the case of wai_sem, or until either the resource has been acquired or a specified time has elapsed,
in the case of twai_sem. The issuance of pol_sem results in a service call error, and the task is informed that
resource acquisition failed.
Tasks in the resource acquisition waiting state are registered in the waiting task queue of the specified semaphore.
It is therefore possible to have multiple tasks waiting for the same semaphore, in which case a request for resource
acquisition sent to a semaphore for which tasks are already waiting will not result in an error; the task will simply be
put in the resource acquisition waiting state.
Tasks can be registered in the waiting task queue of a semaphore by two methods, depending on the attribute
specified when the semaphore was created. One method is registering tasks in the queue in the order of their
priorities, which is used for semaphores with the attribute TA_TPRI. The other method is registering tasks in the
queue in the order in which they requested resources, which is used for semaphores with the attribute TA_TFIFO. If
waiting tasks are released by the issuance of the service call (i)sig_sem, the tasks are always released in order from
the top of the queue.
5.2.4
Returning resources
A resource is returned to a semaphore by issuing the service call (i)sig_sem.
When (i)sig_sem is issued, the kernel checks the waiting queue of the target semaphore and if there are tasks
registered in the queue, it immediately assigns the task at the top of the queue the resource and releases it from the
waiting state. At this time, the value of the resource counter remains unchanged. If there are no tasks registered in
the waiting queue, the resource counter value is incremented by 1. Note that because only one resource can be
manipulated per service call, multiple tasks are never released simultaneously by one issuance of (i)sig_sem.
5.2.5
Obtaining semaphore information
Semaphore information such as the number of resources can be obtained by using the service calls ref_sem and
iref_sem. For details of each service call, refer to
CHAPTER 13
.