On the Semantics of Distributed Reactive Programming: The Cost of Consistency

Abstract

The reactive programming paradigm aims to simplify the development of reactive systems. It provides abstractions to define time-changing values that are automatically updated by the runtime according to their dependencies. The benefits of reactive programming in distributed settings have been recognized for long. Yet, existing solutions for distributed reactive programming enforce the same semantics as in single processes, introducing communication and synchronization costs that hamper scalability. Establishing suitable abstractions for distributed reactive programming demands for a deeper investigation of the semantics of change propagation. This paper takes a foundational approach and defines precise propagation semantics in terms of consistency guarantees that constrain the order and isolation of value updates. We study the benefits and costs of these consistency guarantees both theoretically and empirically, using case studies and synthetic benchmarks. We show that different applications require different levels of consistency and that manually implementing the required level on a middleware that provides a lower one annuls the abstraction improvements of reactive programming. This motivates a framework that enables the developers to select the best trade-off between consistency and overhead for the problem at hand. To this end, we present DREAM, a distributed reactive programming middleware with flexible consistency guarantees.

Implementing a Language for Distributed Systems: Choices and Experiences with Type Level and Macro Programming in Scala

“…Reactive programming [3] provides abstractions for defining time-changing values (signals), event streams and their combination. In line with multitier programming, distributed reactive programming [35,36,29] allows developers to define event streams that span over different machines.…”

A Semantic Framework for the Design of Distributed Reactive Real-Time Languages and Applications

“…Line 7 in listing 11 shows this error, there attribute current-mesg indicates that the current message is number 0, while the attribute logs indicated that the previous message was message number 1. Reactive languages can be used to find states that break FIFO (first-in, first-out) consistency, as researchers in [23] have shown it. For example, imagine a distributed application with one component sending messages and other components receiving messages, as shown in figure 3, imagine then that two observers are deployed in different nodes to check that messages arrive in the order they were emitted.…”

“…For example, using the DREAM middleware, researchers explore in [24] different semantics for distributed reactive systems qualitatively. Furthermore, in [23] the authors present a study for the change propagation cost implementation in DRP, description for DREAM's API and it is consistency implementation on the Java language. Besides, Potato [10] is another example of a distributed reactive programming middleware.…”

GRASS: generic reactive application-specific scheduling

“…Similar to our approach of specifying resource scheduling policies by leveraging reactive programming, FRP has been applied to compute the operator placement for complex event processing operators [36]. Recent research on RP focuses on issues such as concurrency [11], fault tolerance [25], distribution [35,37], different levels of consistency [23] and the application to areas such as autonomous vehicles [13] and IoT and edge computing [5].…”