Reactive, Asynchronous, and Parallel Programming

So far in this book you’ve seen functions and objects that process their inputs immediately using a single “thread” of execution where the code runs to completion and produces useful results or state changes. In this chapter, you’ll turn your attention to concurrent, parallel, asynchronous, and reactive programs. These each represent substantially different approaches to programming from those you’ve seen so far. Some of the reasons for turning to these techniques are as follows: To achieve better responsiveness in a graphical user interface (GUI) To report progress results during a long-running computation and to support cancellation of these computations To achieve greater throughput in a reactive application or service To achieve faster processing rates on a multiprocessor machine or cluster To take advantage of the I/O parallelism available in modern disk drives or network connections To sustain processing while network and disk I/O operations are in process In this chapter, we cover some of the techniques that can help achieve these outcomes: Using .NET threads and the BackgroundWorker class for background computations Using events and messages to report results back to a GUI Using F# asynchronous workflows and the .NET thread pool to handle network requests and other asynchronous I/O operations Using F# pattern matching to process message queues Using low-level .NET shared-memory primitives to implement new concurrency techniques and control access to mutable data structures KeywordsGraphical User InterfaceConcurrent ProgrammingMain ThreadWork ThreadThread PoolThese keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

In asynchronous programming, we embrace the fact that certain operations are best represented by running them separately from the main flow of logic. Instead of stopping everything while we wait for a result, we expect those separate computations to notify us when they have completed, at which point we’ll deal with their results. It’s a bit like one of those restaurants where you order, say, a pizza, and they give you a pager that flashes when your order is ready. You’re free to grab a table and chat with your friends. When the pager goes off, you collect your pizza and carry on with the main business of your visit – eating!

For a GUI to remain responsive, it must be able to schedule lengthy tasks to be executed asynchronously. In the traditional approach to GUI implementation--writing functions to handle individual user events--asynchronous programming easily leads to defects. Ensuring that all data dependencies are respected is difficult when new events arrive while prior events are still being handled. Reactive programming techniques, gaining popularity in GUI programming, help since they make data dependencies explicit and enforce them automatically as variables' values change. However, data dependencies in GUIs usually change along with its state. Reactive programming must therefore describe a GUI as a collection of many reactive programs, whose interaction the programmer must explicitly coordinate. This paper presents a declarative approach for GUI programming that relieves the programmer from coordinating asynchronous computations. The approach is based on our prior work on models, where GUI state is maintained by a dataflow constraint system. A property model responds to user events by atomically constructing new data dependencies and scheduling asynchronous computations to enforce those dependencies. In essence, a property model dynamically generates a reactive program, adding to it as new events occur. The approach gives the following guarantee: the same sequence of events produces the same results, regardless of the timing of those events.

Reactive programming languages and libraries, such as ReactiveX, have been shown to significantly improve software design and have seen important industrial adoption over the last years. Asynchronous applications - which are notoriously error-prone to implement and to maintain - greatly benefit from reactive programming because they can be defined in a declarative style, which improves code clarity and extensibility. In this paper, we tackle the problem of refactoring existing software that has been designed with traditional abstractions for asynchronous programming. We propose 2Rx, a refactoring approach to automatically convert asynchronous code to reactive programming. Our evaluation on top-starred GitHub projects shows that 2Rx is effective with the most common asynchronous constructs, covering 12.7% of projects with asynchronous computations, and it can provide a refactoring for 91.7% of their occurrences.

Supporting asynchronization in OpenMP for event-driven programming

The following topics are dealt with: parallel processing; learning (artificial intelligence); graphics processing units; graph theory; parallel algorithms; scheduling; application program interfaces; parallel architectures; storage management; parallel machines.