The mm_medium
Communication is modeled explicitly using objects
that are called media. A medium is defined with a set of variables
and functions. Values of the variables constitute states of the
medium. The variables can be referenced only by the functions
defined in the medium, and communication among processes is
established by calling
these functions to change or evaluate the states of media.
This mechanism has been chosen for two reasons:
- it allows communication semantics to be modeled solely
by specifying media, independent from process specifications
- it allows an efficient synchronization access on
shared resources
The mechanism that handles the medium access is shown in the following figure
Consider two processes P1 and P2. P1 requests access to the
medium in order to set a variable to value x. Another process,
P2, is waiting on a guard condition that involves the same
variable.
The synchronization mechanism involves the following core-lib
elements:
The synchronization protocol is the following:
- process P1 requests access to the medium throughout a
port derived from mm_port_base base class;
- mm_port_base forwards the request to mm_port_mgr that
atomically checks if the port is free and locks access to itself
for different processes than P1;
- P1 now writes the new value;
- when P1 releases the port lock the mm_port_mgr awakes
all the processes (in the example P2) that were waiting on
that condition.
Internally core-lib relies upon Posix threads conditional variables
to efficiently manage accesses.
In particular the following Posix standard functions are used:
- pthread_mutex_lock and pthread_mutex_unlock
to lock and unlock a mutex respectively;
- pthread_cond_wait and pthread_cond_broadcast
to wait on and signal a conditional variable respectively.
If the port is not released deadlock may occur. The simulator
provides some deadlock detection techniques that help the developer
understand which process has locked a resource indefinitely
(deadlock).