CHAPTER 6 EXTENDED SYNCHRONIZATION AND COMMUNICATION FUNCTIONS

---

This chapter describes the extended synchronization and communication functions performed by the RI850V4.

6.1 Outline

The RI850V4 provides Mutexes as the extended synchronization and communication function for implementing exclusive control between tasks.

6.2 Mutexes

Multitask processing requires the function to prevent contentions on using the limited number of resources (A/D converter, coprocessor, files, or the like) simultaneously by tasks operating in parallel (exclusive control function). To resolve such problems, the RI850V4 therefore provides "mutexes".

The following shows a processing flow when using a mutex.

The mutexes provided in the RI850V4 do not support the priority inheritance protocol and priority ceiling protocol but only support the FIFO order and priority order.

Figure 6-1 Processing Flow (Mutex)

6.2.1 Differences from semaphores

Since the mutexes of the RI850V4 do not support the priority inheritance protocol and priority ceiling protocol, so it operates similarly to semaphores (binary semaphore) whose the maximum resource count is 1, but they differ in the following points.

- A locked mutex can be unlocked (equivalent to returning of resources) only by the task that locked the mutex

--> Semaphores can return resources via any task and handler.

- Unlocking is automatically performed when a task that locked the mutex is terminated (ext_tsk or ter_tsk)

--> Semaphores do not return resources automatically, so they end with resources acquired.

- Semaphores can manage multiple resources (the maximum resource count can be assigned), but the maximum number of resources assigned to a mutex is fixed to 1.

6.2.2 Create mutex

In the RI850V4, the method of creating a mutex is limited to "static creation".

Mutexes therefore cannot be created dynamically using a method such as issuing a service call from a processing program.

Static mutex creation means defining of mutexes using static API "CRE_MTX" in the system configuration file.

For details about the static API "CRE_MTX", refer to "17.5.6 Mutex information".

6.2.3 Lock mutex

Mutexes can be locked by issuing the following service call from the processing program.

- loc_mtx
This service call locks the mutex specified by parameter mtxid.
If the target mutex could not be locked (another task has been locked) when this service call is issued, this service call queues the invoking task to the target mutex wait queue and moves it from the RUNNING state to the WAITING state (mutex wait state).
The WAITING state for a mutex is cancelled in the following cases, and then moved to the READY state.

WAITING State for a Mutex Cancel Operation	Return Value
The locked state of the target mutex was cancelled as a result of issuing unl_mtx.	E_OK
The locked state of the target mutex was cancelled as a result of issuing ext_tsk.	E_OK
The locked state of the target mutex was cancelled as a result of issuing ter_tsk.	E_OK
Forced release from waiting (accept rel_wai while waiting).	E_RLWAI
Forced release from waiting (accept irel_wai while waiting).	E_RLWAI

The following describes an example for coding this service call.

#include <kernel.h> /*Standard header file definition*/ #include <kernel_id.h> /*System information header file definition*/ void task (VP_INT exinf) { ER ercd; /*Declares variable*/ ID mtxid = ID_MTX1; /*Declares and initializes variable*/ ......... ercd = loc_mtx (mtxid); /*Lock mutex (waiting forever)*/ if (ercd == E_OK) { ......... /*Locked state*/ unl_mtx (mtxid); /*Unlock mutex*/ } else if (ercd == E_RLWAI) { ......... /*Forced termination processing*/ } ......... }

Note 1 Invoking tasks are queued to the target mutex wait queue in the order defined during configuration (FIFO order or priority order).

Note 2 In the RI850V4, E_ILUSE is returned if this service call is re-issued for the mutex that has been locked by the invoking task (multiple-locking of mutex).

- ploc_mtx
This service call locks the mutex specified by parameter mtxid.
If the target mutex could not be locked (another task has been locked) when this service call is issued but E_TMOUT is returned.
The following describes an example for coding this service call.

#include <kernel.h> /*Standard header file definition*/ #include <kernel_id.h> /*System information header file definition*/ void task (VP_INT exinf) { ER ercd; /*Declares variable*/ ID mtxid = ID_MTX1; /*Declares and initializes variable*/ ......... ercd = ploc_mtx (mtxid); /*Lock mutex (polling)*/ if (ercd == E_OK) { ......... /*Polling success processing*/ ......... unl_mtx (mtxid); /*Unlock mutex*/ } else if (ercd == E_TMOUT) { ......... /*Polling failure processing*/ } ......... }

Note In the RI850V4, E_ILUSE is returned if this service call is re-issued for the mutex that has been locked by the invoking task (multiple-locking of mutex).

- tloc_mtx
This service call locks the mutex specified by parameter mtxid.
If the target mutex could not be locked (another task has been locked) when this service call is issued, this service call queues the invoking task to the target mutex wait queue and moves it from the RUNNING state to the WAITING state with timeout (mutex wait state).
The WAITING state for a mutex is cancelled in the following cases, and then moved to the READY state.

WAITING State for a Mutex Cancel Operation	Return Value
The locked state of the target mutex was cancelled as a result of issuing unl_mtx.	E_OK
The locked state of the target mutex was cancelled as a result of issuing ext_tsk.	E_OK
The locked state of the target mutex was cancelled as a result of issuing ter_tsk.	E_OK
Forced release from waiting (accept rel_wai while waiting).	E_RLWAI
Forced release from waiting (accept irel_wai while waiting).	E_RLWAI
Polling failure or timeout.	E_TMOUT

The following describes an example for coding this service call.

#include <kernel.h> /*Standard header file definition*/ #include <kernel_id.h> /*System information header file definition*/ void task (VP_INT exinf) { ER ercd; /*Declares variable*/ ID mtxid = ID_MTX1; /*Declares and initializes variable*/ TMO tmout = 3600; /*Declares and initializes variable*/ ......... ercd = tloc_mtx (mtxid, tmout); /*Lock mutex (with timeout)*/ if (ercd == E_OK) { ......... /*Locked state*/ unl_mtx (mtxid); /*Unlock mutex*/ } else if (ercd == E_RLWAI) { ......... /*Forced termination processing*/ } else if (ercd == E_TMOUT) { ......... /*Timeout processing*/ } ......... }

Note 1 Invoking tasks are queued to the target mutex wait queue in the order defined during configuration (FIFO order or priority order).

Note 2 In the RI850V4, E_ILUSE is returned if this service call is re-issued for the mutex that has been locked by the invoking task (multiple-locking of mutex).

Note 3 TMO_FEVR is specified for wait time tmout, processing equivalent to loc_mtx will be executed. When TMO_POL is specified, processing equivalent to ploc_mtx will be executed.

6.2.4 Unlock mutex

The mutex locked state can be cancelled by issuing the following service call from the processing program.

- unl_mtx
This service call unlocks the locked mutex specified by parameter mtxid.
If a task has been queued to the target mutex wait queue when this service call is issued, mutex lock processing is performed by the task (the first task in the wait queue) immediately after mutex unlock processing.
As a result, the task is unlinked from the wait queue and moves from the WAITING state (mutex wait state) to the READY state, or from the WAITING-SUSPENDED state to the SUSPENDED state.
The following describes an example for coding this service call.

#include <kernel.h> /*Standard header file definition*/ #include <kernel_id.h> /*System information header file definition*/ void task (VP_INT exinf) { ER ercd; /*Declares variable*/ ID mtxid = ID_MTX1; /*Declares and initializes variable*/ ......... ercd = loc_mtx (mtxid); /*Lock mutex*/ if (ercd == E_OK) { ......... /*Locked state*/ unl_mtx (mtxid); /*Unlock mutex*/ } else if (ercd == E_RLWAI) { ......... /*Forced termination processing*/ } ......... ......... }

Note A locked mutex can be unlocked only by the task that locked the mutex.
If this service call is issued for a mutex that was not locked by an invoking task, no processing is performed but E_ILUSE is returned.

6.2.5 Reference mutex state

A mutex status is referenced by issuing the following service call from the processing program.

- ref_mtx, iref_mtx
The service calls store the detailed information of the mutex specified by parameter mtxid (existence of locked mutexes, waiting tasks, etc.) into the area specified by parameter pk_rmtx.
The following describes an example for coding this service call.

#include <kernel.h> /*Standard header file definition*/ #include <kernel_id.h> /*System information header file definition*/ void task (VP_INT exinf) { ID mtxid = ID_MTX1; /*Declares and initializes variable*/ T_RMTX pk_rmtx; /*Declares data structure*/ ID htskid; /*Declares variable*/ ID wtskid; /*Declares variable*/ ATR mtxatr; /*Declares variable*/ ......... ref_mtx (mbxid, &pk_rmtx); /*Reference mutex state*/ htskid = pk_rmtx.htskid; /*Acquires existence of locked mutexes*/ wtskid = pk_rmtx.wtskid; /*Reference ID number of the task at the */ /*head of the wait queue*/ mtxatr = pk_rmtx.mtxatr; /*Reference attribute*/ ......... }

Note For details about the mutex state packet, refer to "15.2.8 Mutex state packet".