Browse Prior Art Database

Making synchronous software asynchronous

IP.com Disclosure Number: IPCOM000241844D
Publication Date: 2015-Jun-03
Document File: 5 page(s) / 24K

Publishing Venue

The IP.com Prior Art Database

Abstract

Large software stacks are often “synchronous” (or “blocking”), such that API functions return only once all the underlying operations are complete . Whereas “asynchronous” software will expose APIs that initiate operations and return control quickly without necessarily waiting for operations to complete. Asynchronous programming models adapt better to situations where the underlying operations need to be offloaded (eg. parallel or distributed computing, hardware acceleration, remote data-retrieval …), but as a general rule are significantly more complex to implement than comparable synchronous models. This complexity adds its own overhead, for one thing, and also increases the potential for bugs. Converting synchronous software to an asynchronous form is also a complicated undertaking in itself. The method described here allows for such software stacks to be “made asynchronous” with minor modifications, using fibres, coroutines, and careful attention paid to locking.

This text was extracted from a Microsoft Word document.
This is the abbreviated version, containing approximately 39% of the total text.

Making synchronous software asynchronous

Using fibres, coroutines, locking hooks, and thread-local storage.

Abstract

Large software stacks are often “synchronous” (or “blocking”), such that API functions return only once all the underlying operations are complete[1]. Whereas “asynchronous” software will expose APIs that initiate operations and return control quickly without necessarily waiting for operations to complete. Asynchronous programming models adapt better to situations where the underlying operations need to be offloaded (eg. parallel or distributed computing, hardware acceleration, remote data-retrieval …), but as a general rule are significantly more complex to implement than comparable synchronous models. This complexity adds its own overhead, for one thing, and also increases the potential for bugs. Converting synchronous software to an asynchronous form is also a complicated undertaking in itself.

The method described here allows for such software stacks to be “made asynchronous” with minor modifications, using fibres, coroutines, and careful attention paid to locking.

About coroutines and fibres

Coroutines

A conventional “routine” (or “function call”) is a unit of software to which another unit of software (the “caller”) passes execution control together with input parameters, and execution control is later returned to the caller by the routine as it completes, when results and outputs of the routine are available.

The notion of a “coroutine” extends that of a routine by supporting suspend and resume semantics. I.e. control can be returned to the caller before the coroutine’s function is complete, and control can be passed back to the coroutine multiple times before it finally returns in a completed state.

Fibres

Whereas thread-based programming is commonly used for synchronous-style codebases, as multitasking and parallelism comes from the ability to run multiple threads, the use of fibres is quite the opposite! Independent of any parallelism, fibre-based logic allows any single thread of execution to support separate instances of runnable but paused function calls, and explicitly suspend and switch control to whichever fibre should resume and run next.

Fibres are named according to the metaphor that they are similar to but thinner than threads.

Relative equivalence between coroutines and fibres

For our purposes here, fibres and coroutines are largely interchangeable terms. E.g. if a system provides an implementation of fibres, then one can straightforwardly implement coroutines on top of that, and the converse is true also. (Though constructing fibres out of coroutines is likely to be inefficient.)

Some cases will naturally align to the notion of fibres, and others to coroutines. This method is about running synchronous operations in a fibre and suspending it, to expose asynchronous semantics. The distinction between coroutines and fibres is about “which fibre to switch to”, which is n...