Wed Aug 19 09:41:44 EDT 2020
So what is the relation between polling a condition (e.g. timer ==
timeout), and having a CSP event?
There seems to be a subtle difference...
First transformation that can be made is to move the condition from
reader to writer. E.g. the system interface will produce an event
when the condition happens.
But what I do not quite understand is: what happens with events that
are not read? In the condition architecture, this is implicit:
control flow just happens, and does't poll certain conditions in
certain execution paths.
So it seems that the real issue is in moving the condition from reader
to writer. e.g. the writer doesn't know whether the event needs to be
produced or not.
How to express that in csp? In the case of the timer, it would
e.g. mean that the timer selects on all its writes, and if a later one
happens, it can discard an earlier one?
There seems to be a fundamental difference.
Find a better way to represent this.
The fundamental idea is causal relationships. In the case of
condition synchronization, there is a shared world. Tasks can mutate
the shared world, and tasks can wait for conditions computed form the
shared world. When a task resumes operation, that can be seen as an
event at that task's end, but it is not an event anywhere else. Event
is just not the correct abstraction.
What am I missing?
To re-iterate: the thing causing a condition to become true is an
event, but it is implicit.
It is probably possible to represent the event through the derivative
of the blocking condition. I.e. the operation of deriving makes the
event explicit, but otherwise it has no explicit representation.