In order to be as portable as possible while remaining efficient, the Ease library has a reasonably complex model for the host it is running on. The term "host" as used here refers to the collection of processes that a program runs on, whether that be a single unix process containing multiple threads, or multiple processes on multiple machines connected by some network.
The Ease library allows for processes to reside in shared or separate (distributed) address spaces.
Shared memory between Ease processes occurs through the use of a threads package, such as xxx Cite threads references here. Threads may be supported by the kernel or by a user level library, and may run on separate processors on the physical machine or be switched on a single processor machine.
The Ease library supports preemptive and non-preemptive thread libraries.
Control may switch between preemptive threads at any time (or they may run simultaneously if multiple processors are available), so care must be taken to avoid simultaneous access of shared resources (such as contexts) by use of locks. To control access to shared resources the host interface (section 5.7) provides two types of locks: mutexes and semaphores.
Mutexes allow a process to lock a resource multiple times. This permits lock/unlock pairs to be placed around critical portions of code without regard to whether the mutex has already been locked by this process (as would be necessary if a semaphore was used). A counter is kept of the number of locks held by a process and when this reaches zero another process waiting on the mutex may lock it.
Semaphores are used for signalling a process that it may proceed (for instance when the data it was waiting for is not available). Monitors are unsuitable for this task since a race condition may occur where the signal (unlock) occurs before the wait (lock) does.
Where non-preemptive threads are used, the Ease library controls all scheduling (see section 5.5). No locking or signalling occurs since the order of execution is completely controlled and hence no switches can occur in critical regions of the library.
The Ease
library may also run on distributed memory multiprocessors or
on a network of machines. Implementations currently exist for
xxx cite host architectures here.
Processes (or groups of processes/threads) in
distributed memory implementation have separate address spaces. Each
separate address space we call a cell
. Each cell has a unique global
identifier which allows any other cell to send it messages.
The majority of message passing libraries used have an interface which passes an integer message type together with a block of data. The library packs the destination thread and an Ease message type into the message type sent with a message to avoid extra copying overhead where possible (there is likely to be further copying within the message passing library used anyway).
Note that a combination of shared and distributed memory is possible. This is useful where a limited number of cells are available.
The current implementation assumes a single architecture for all cells, and also that a function pointer value points to the same function in all cells. More specifically, it is required that functions generated by the Ease compiler are not relocated differently in different cells.
Next: Process Implementation
Up: Implementation
Previous: Implementation