Atomic transactions

[gordonbrander]

In functional reactive programming formulations, observables (sometimes called "events" or "streams") implement the concept of an atomic "moment". Observables that fire at the same time will update during the same atomic moment. Within a discrete push-based FRP system, such as observables, this is typically implemented using some kind of transaction system.

Atomic transactions prevent inconsistent state issues, where some upstream observables have updated, while other downstream observables have not yet updated, resulting in different views of state. This kind of inconsistent state issue can be caused by order of callback registration, or by the "diamond problem" (see below).

Has there been any discussion within the Observable WG around atomic updates? Is this something that might be considered? Thanks!

Background

Atomicity makes it possible to create networks of observables that update together, during the same conceptual moment, avoiding inconsistent states that arise due to order of callback registration, or when merging multiple observables.

One area where this often comes up is the so-called "diamond problem". Picture a network of observables:

     A
   /   \
  B     C
   \   /
     D
     |
     E

Where A is a source, B and C are mapped from A, and D merges B and C together. E is writing to some sink. A is sent a new value. What happens next?

• Without atomicity: B and C are updated. The order in which they are updated depends upon the order of callback registration. The order may affect the value of D. Next, D and E are updated twice, once for the event sent to B and once for the event sent to C. E performs two writes, one with the intermediate state ("glitch"), and then one more.
• With atomicity: A, B, C, D and E are all updated during the same "moment" (typically through a transaction system). D and E are only updated once, E only writes once, and no intermediate state is written.

An FRP observable system that implements transactions is sometimes called "glitch-free", since it avoids the kinds of glitches that can be caused by inconsistent/intermediate states.

To combine simultaneous events, transactions typically include the concept of a "merge" function ((left, right) => choice) that allows the developer to choose between simultaneous events, or otherwise combine them into a single event for that transaction.

In addition to more deterministic/reliable state updates that do not depend upon order of callback registration or position in the network, atomicity can also allow Observable streams to be combined with other concepts such as FRP signals (atomically updated reactive state containers, sometimes called "behaviors" or "cells"). When both observables and signals are atomic, observables can sample from, and update signals without problems of inconsistent state.