What are use cases for coroutines?

Viewed 16756

The concept of a coroutine sounds very interesting, but I don't know, if it makes sense in a real productive environment? What are use cases for coroutines, where the coroutine implementation is more elegant, simpler or more efficient than other methods?

9 Answers

One use case is a web server that has multiple simultaneous connections, with a requirement to schedule reading and writing in parallel with all of them.

This can be implemented using coroutines. Each connection is a coroutine that reads/writes some amount of data, then yields control to the scheduler. The scheduler passes to the next coroutine (which does the same thing), cycling through all the connections.

Unix pipes are a use case:

grep TODO *.c | wc -l

The pipeline above is a coroutine. The grep command generates a sequence of lines and writes them to a buffer. The wc command reads these lines from the buffer. If the buffer fills up, then grep "blocks" until the buffer empties. If the buffer is empty, then wc waits for more input in the buffer.

Coroutines are more often used in more constrained patterns, like the Python generators mentioned, or as pipelines.

For more details and examples, read the Wikipedia articles, particularly coroutines and iterators.

True coroutines require language support. They need to be implemented by the compiler and supported by the underlying framework.

One language-supported implementation of coroutines is the C# 2.0 yield return keyword, which allows you to write a method that returns multiple values for looping.

The yield return does have limitations, however. The implementation uses a helper class to capture state, and it only supports the specific case of a coroutine as a generator (iterator).

In a more general case, an advantage of coroutines is that they make certain state-based computations easier to express and easier to understand. For example, implementing a state machine as a set of coroutines can be more elegant than other implementations. But doing this requires language support that doesn't yet exist in C# or Java.

Coroutines are useful to implement producer/consumer patterns.

For example, Python introduced coroutines in a language feature called generators, which was intended to simplify the implementation of iterators.

They can also be useful to implement cooperative multitasking, where each task is a coroutine that yields to a scheduler/reactor.

As a producer/consumer example, a batch reporting program be implemented with coroutines.

The key hint for that example is having nontrivial work to consume input data (e.g. parsing data or accumulating charges and payments on an account), and nontrivial work to produce the output. When you have these characteristics, then:

  • It is easy to organize/understand the input-side code if you can write units of work at various places.
  • It is likewise easy to organize/understand the output-side code if it can read the next unit of work in a nested control structure.

then coroutines and queues are both nice techniques to have at your disposal.

One use case: In-Memory DataBase Systems.

Coroutines can be used for reducing CPU stalls due to cache misses caused by lookups in such database systems, like hash probes or B+-tree traversals.

Database systems use many pointer-based data structures, including hash tables and B+-trees, which require extensive "pointer-chasing" during a hash probe or a B+-tree traversal. When a batch of operations arrive at the same time, Coroutines can easily interleave the instruction flow between operations, thereby reducing CPU stalls caused by cache misses, taking advantage of the parallelism of memory access.

A quick look at the answers above gives me the impression that they focus on execution speed and that one of the other interesting features of true coroutines is being ignored: that they can communicate values. For sure in low-level code, and in Python.

One use case would be to pit two game-playing programs against each other -- each would submit its next move to the other. The advantage is that the code reads more naturally: each coroutine regards the other as a function -- send a move and receive and answer. The same sort of thing arises in simulations, and probably other problems.

In contrast, the examples above send data in only one direction (generators) if they send any data at all.

Related