Wed Aug 19 11:49:59 EDT 2020

From condtions to events

The practical problem I face is to bridge events (essentially,
interrupt occured, data is available), with conditions: did a timeout
expire, did a certain flag go fron 0->1?

It seems that automatically deriving the condition poll into a
schedulable event is not straightforward, but let's try anyway.

1. Did timeout expire?

If that is the only blocking point, it is easy to translate the
evaluation into the creation of an event: take the difference, set a
timer, wake the task up again after timeout.

2. Did the other task read from a buffer?  Or generically, set a flag?

This can be done by intercepting the actual change.  If it is a task,
it should somehow register its output change to the scheduler.  If it
is hardware, it should enable an interrupt and go from there.

It seems trivial.

Why is this so hard in practice?

Because it has to be done for each condition that might effect another

So the man benefits of polled conditional synchronization is not so
much that the inputs are easier to specify, but that the outputs are

To the problem that needs to be solved is to make outputs explicit.

This can be done by adding notifications.  This is a simple addition
that "implements" power efficiency.  I.e. polls can just remain.  It
is also possible to connect outputs to inputs directly with a data
structure, but that doesn't seem possible without a code

No matter how I turn this: events are just more concrete.  There is no
free stuff here, apart from program transformation that would turn a
mutation into an event behind the scenes.

Bottom line:

1. conditions, implemented via polling, seem to be much simpler to
   work with in my current setting, especially when a lot of timing
   decisions need to be made.

2. if power efficiency is needed, convert to some standard evented

3. if power efficiency is clear from the start, then use an evented
   architecture to begin with. better to start off with a properly
   engineered design.