Scheduling enclaves
The goal is to decouple Reactors and avoid dependencies introduced by the global barrier synchronization. In the following program, e2 could execute at a logical tag which is up to 100 msec greater than the current tag of e1. Scheduling enclaves enable this.
Each enclave will be associated with an environment_t struct which holds all previously global data structures, except for data structures related to the tokens. The environment_t also contains a pointer to a scheduler and a set of worker threads.
Most functions in the run-time will need to take and additional environment_t* argument to know which event queues, mutexes, etc to work with. The self_base_t struct is also extended with an environment_t* field such that all reactors are also associated with an environment.
The following is the set of connections patterns that we consider among enclaves
The proposal is to implement the enslaved connections as a generated reactor we refer to as ConnectionReactor The ConnectionReactor will be similar to the ones created for Physical and Delayed Connections. The Enclave to Enclave connection will look like this:
The ConnectionReactor will officially belong to the environment of the destination reactor. I.e. e2. However, the input reaction, with index 2, is executed in the environment of the source reactor. While executing in the environment of the source reactor it must be able to schedule a logical action that belongs to the destination. I.e. it puts events on the event queue of another environment.
The ConnectionReactor will have two state variables. source_environment and destination_environment. The code-generator will have to initialize these to be pointers to the source and destination environments, respectively. Technically, the destination environment pointer is redundant, but it is there for clarity.
Due to both the reactions in the ConnectionReactor exchanging tokens through the action on the self-struct, there has to be some mutual exclusion between them. This would normally be implemented by the level assignments, but as they execute in different environments they might execute concurrently. This can be achieved by adding a reactor_mutex on the self-struct which then both environments will have to acquire.
This means that we will have the following mutex acquisitions in the ConnectionReactor: