package alternation
- Alphabetic
- Public
- All
Type Members
-
sealed
class
Run
extends Runnable with debug.REGISTRY.Debuggable
Manages the state of a running alternation construct whose abstract syntax is
syntax
.Manages the state of a running alternation construct whose abstract syntax is
syntax
. IfregisterWithDebugger
istrue
then the alternation construct is registered with the debugger while it runs. This is for in-extremis debugging of deadlocking CSO code that includes alternations.Alternations happen in four phases (these phases are almost the same for alt, prialt, serve and priserve constructs), namely: Registration, Waiting, Unregistration, and Execution.
- Registration: The current feasibility of all participating events is
recorded as
UNKNOWNSTATE
,INFEASIBLE
, orREADYSTATE
, and their associated ports are marked as being involved in this running alternation construct. An event for a port that is closed at this stage will never become feasible. An event is infeasible if its associated port has been closed, or if its associated guard is false. - Waiting: If, after registration, no
READYSTATE
event is present, but some events are still feasible, then the alternation will wait (with the appropriate deadline, if there's an after event; and sine-die otherwise) for a port to change state. If there's an after event and the wait timed-out, then the after event is marked to be executed. If no events are feasible by this phase, or if the last feasible event becomes infeasible as a consequence of a state change (because its port closed during the wait), then the orelse path is taken, to wit: the orelse event (if any) is marked to be executed. - Unregistration: All ports of all feasible events are now unregistered from their participation in this running alt. If during this phase any already-feasible events are found to be ready then one of them is chosen and marked for execution. The precise method of choice depends on whether or not the alternation construct is supposed to be fair. In this implementation all but serve alternations choose the first event (in order of appearance in the alternation) found to be ready during unregistration. (Unregistration of feasible events actually takes place in reverse order of appearance in the alternation, giving "higher priority" feasible events a little more time to become ready.)
- Execution: When all event ports have been unregistered, then:
- If a feasible event has been marked for execution, then it is executed; or
- If after has been marked for execution, then it is executed; or
- If orelse has been marked for execution, then it is executed (and if the executing alternative is a serve, the serve is terminated)
- If nothing has been marked for execution, then an alt or prialt will abort; and a serve or priserve will terminate.
The present implementation is highly unadventurous and may be less than optimally efficient, though it is (intended to be) scrutable. My experience has been that alternation is tricky to implement efficiently without introducing race conditions that are hard to track down.
Possible improvements/speedups include:
- Run the first event found to be ready during registration in an
priserve
orprialt
. - Give the programmer more control of the algorithm that chooses fairly between events
run during the execution of a
serve
. Theround-robin
method is not always effective -- particularly when certain patterns of guarded event are present in the alternation. - Distinguish between
alt
andprialt
implementation by using an efficient source of randomness to choose among events that become ready before unregistration.
@author Bernard Sufrin, Oxford, $Revision: 316 $, $Date: 2018-01-11 18:18:45 +0000 (Thu, 11 Jan 2018) $
- Registration: The current feasibility of all participating events is
recorded as
-
trait
Runnable
extends AnyRef
Interface between (the abstract syntax of) events and the specific implementations of
alt
andserve
(etc) used in a CSO implementation.Interface between (the abstract syntax of) events and the specific implementations of
alt
andserve
(etc) used in a CSO implementation.@author Bernard Sufrin, Oxford $Revision: 212 $ $Date: 2017-09-29 18:07:56 +0100 (Fri, 29 Sep 2017) $
Value Members
-
object
AltAbort
extends Stopped with Product with Serializable
The
Stopped
exception raised by analt/prialt
with noorelse
clause when it is has run out of feasible events that might become ready. -
object
IgnorePortEvents
extends Runnable
A
Runnable
that ignores port event notifications. -
object
LoggingFlags
Flags used to control the level of detail recorded when the execution of alternations is logged.