Reply-to: Nat Goodspeed ( nat at lindenlab dot com) Oliver Kowalke (oliver dot kowalke at gmail dot com) Distinguishing coroutines and fiber

Programming Language C

CiteSeerX

Document number: N4024
Date: 2014-05-22
Project: Programming Language C++, SG1
Reply-to: Nat Goodspeed ( nat at lindenlab dot com)
Oliver Kowalke (oliver dot kowalke at gmail dot com)
Distinguishing coroutines and ﬁbers
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Fibers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Coroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Overview
The purpose of this paper is to foreshadow a forthcoming proposal to introduce ﬁbers to the C++ standard library;
to brieﬂy describe the features in the proposed ﬁber library; and to contrast it with the coroutine library proposed in
N3985
6.
It is hoped that this comparison will help to clarify the feature set of the proposed coroutine library. Certain fea-
tures properly belong in the coroutine library; other conceptually-related features more properly belong in the ﬁber
library.
Background
A coroutine library was initially proposed in N3708
4; the proposal was subsequently revised in N3985
6. Some of the
ensuing discussion suggests that, for purposes of reﬁning the coroutine proposal, it might be useful for the authors to
disambiguate the conceptual space addressed by the coroutine library from the conceptual space addressed by the ﬁber
library.
Fibers
A Quick Sketch of the Fiber Library
For purposes of this paper, we can regard the term ‘ﬁber’ to mean ‘user-space thread.’ A ﬁber is launched, and concep-
tually it can have a lifespan independent of the code that launched it. A ﬁber can be detached from the launching code;
alternatively, one ﬁber can join another. A ﬁber can sleep until a speciﬁed time, or for a speciﬁed duration. Multiple
conceptually-independent ﬁbers can run on the same kernel thread. When a ﬁber blocks, for instance waiting for a
result that’s not yet available, other ﬁbers on the same thread continue to run. ‘Blocking’ a ﬁber implicitly transfers
control to a ﬁber scheduler to dispatch some other ready-to-run ﬁber.
Fibers conceptually resemble kernel threads. In fact, the forthcoming ﬁber library proposal intentionally emulates
much of the std::thread API. It provides ﬁber-local storage. It provides several variants of ﬁber mutexes. It provides
condition_variables and barriers. It provides bounded and unbounded queues. It provides future, shared_future,
promise and packaged_task. These ﬁber-oriented synchronization mechanisms diﬀer from their thread counterparts in
that when (for instance) a mutex blocks its caller, it blocks only the calling ﬁber – not the whole thread on which that
ﬁber is running.
When a ﬁber blocks, it cannot assume that the scheduler will awaken it the moment its wait condition has been
satisﬁed. Satisfaction of that condition marks the waiting ﬁber ready-to-run; eventually the scheduler will select that
ready ﬁber for dispatch.
The key diﬀerence between ﬁbers and kernel threads is that ﬁbers use cooperative context switching, instead of pree-
mptive time-slicing. Two ﬁbers on the same kernel thread will not run simultaneously on diﬀerent processor cores. At
most one of the ﬁbers on a particular kernel thread can be running at any given moment.
1This has several implications:
 Fiber context switching does not engage the kernel: it takes place entirely in user space. This permits a ﬁber
implementation to switch context signiﬁcantly faster than a thread context switch.
 Two ﬁbers in the same thread cannot execute simultaneously. This can greatly simplify sharing data between
such ﬁbers: it is impossible for two ﬁbers in the same thread to race each other. Therefore, within the domain
of a particular thread, it is not necessary to lock shared data.
 The coder of a ﬁber must take care to sprinkle voluntary context switches into long CPU-bound operations. Since
ﬁber context switching is entirely cooperative, a ﬁber library cannot guarantee progress for every ﬁber without
such precautions.
 A ﬁber that calls a standard library or operating-system function that blocks the calling thread will in fact block
the entire thread on which it is running, including all other ﬁbers on that same thread. The coder of a ﬁber
must take care to use asynchronous I/O operations, or operations that engage ﬁber blocking rather than thread
blocking.
In eﬀect, ﬁbers extend the concurrency taxonomy:
 on a single computer, multiple processes can run
 within a single process, multiple threads can run
 within a single thread, multiple ﬁbers can run.
A Few Fiber Use Cases
A ﬁber is useful when you want to launch a (possibly complex) sequence of asynchronous I/O operations, especially
when you must iterate or make decisions based on their results.
Distinct ﬁbers can be used to perform concurrent asynchronous fetch operations, aggregating their results into a
ﬁber-speciﬁc queue for another ﬁber to consume.
Fibers are useful for organizing response code in an event-driven program. Typically, an event handler in such a
program cannot block its calling thread: that would stall handlers for all other events, such as mouse movement.
Handlers must use asynchronous I/O instead of blocking I/O. A ﬁber allows a handler to resume upon completion of
an asynchronous I/O operation, rather than breaking out subsequent logic as a completely distinct handler.
Fibers can be used to implement a task handling framework to address the C10K-problem.
1
For instance strict fork-join task parallelism
5 with its two ﬂavours - fully-strict computation
5 (no task can proceed until
it joins all of its child-tasks) and terminally-strict computations
5 (child-tasks are joined only at the end of processing)
- can be supported.
Furthermore, diﬀerent scheduling strategies are possible: work-stealing and continuation-stealing.
For work-stealing, the scheduler creates a child-task (child-ﬁber) and immediately returns to the caller. Each child-task
(child-ﬁber) is executed or stolen by the scheduler based on the available resources (CPU etc.).
For continuation-stealing, the scheduler immediately executes the spawned child-task (child-ﬁber); the rest of the func-
tion (continuation) is stolen by the scheduler as resources are available.
Coroutines
A Quick Recap of the Coroutine Library
A coroutine is instantiated and called. When the invoker calls a coroutine, control immediately transfers into that
coroutine; when the coroutine yields, control immediately returns to its caller (or, in the case of symmetric coroutines,
to the designated next coroutine).
A coroutine does not have a conceptual lifespan independent of its invoker. Calling code instantiates a coroutine,
passes control back and forth with it for some time, and then destroys it. It makes no sense to speak of ‘detaching’
a coroutine. It makes no sense to speak of ‘blocking’ a coroutine: the coroutine library provides no scheduler. The
coroutine library provides no facilities for synchronizing coroutines: coroutines are already synchronous.
Coroutines do not resemble threads. A coroutine much more closely resembles an ordinary function, with a semantic
extension: passing control to its caller with the expectation of being resumed later at exactly the same point. When
the invoker resumes a coroutine, the control transfer is immediate. There is no intermediary, no agent deciding which
coroutine to resume next.
2A Few Coroutine Use Cases
Normally, when consumer code calls a producer function to obtain a value, the producer must return that value to the
consumer, discarding all its local state in so doing. A coroutine allows you to write producer code that ‘pushes’ values
(via function call) to a consumer that ‘pulls’ them with a function call.
For instance, a coroutine can adapt callbacks, as from a SAX parser, to values explicitly requested by the consumer.
Moreover, the proposed coroutine library provides iterators over a producer coroutine so that a sequence of values
from the producer can be fed directly into an STL algorithm. This can be used, for example, to ﬂatten a tree structure.
Coroutines can be chained: a source coroutine can feed values through one or more ﬁlter coroutines before those
values are ultimately delivered to consumer code.
In all the above examples, as in every coroutine usage, the handshake between producer and consumer is direct and
immediate.
Relationship
The authors have a reference implementation of the forthcoming ﬁber library (boost.ﬁber
3). The reference implement-
ation is entirely coded in portable C++; in fact its original implementation was entirely in C++03.
This is possible because the reference implementation of the ﬁber library is built on boost.coroutine
2, which provides
context management. The ﬁber library extends the coroutine library by adding a scheduler and the aforementioned
synchronization mechanisms.
Of course it would be possible to implement coroutines on top of ﬁbers instead. But the concepts map more neatly to
implementing ﬁbers in terms of coroutines. The corresponding operations are:
 a coroutine yields;
 a ﬁber blocks.
When a coroutine yields, it passes control directly to its caller (or, in the case of symmetric coroutines, a designated
other coroutine).
When a ﬁber blocks, it implicitly passes control to the ﬁber scheduler. Coroutines have no scheduler because they
need no scheduler.
Summary
It is hoped that this paper will help to illuminate some perceived omissions in the proposed coroutine library, so that
the reader can properly associate desired functionality with the coroutine library proposal versus the forthcoming ﬁber
library proposal
References
[1] The C10K problem, Dan Kegel
[2] boost.coroutine
[3] boost.ﬁber
[4] N3708: A proposal to add coroutines to the C++ standard library
[5] N3832: Task Region
[6] N3985: A proposal to add coroutines to the C++ standard library (Revision 1)
3

Document number: N4024 Date: 2014-05-22 Project:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4024.pdf

Document number: N4024 Date: 2014-05-22 Project:

Abstract

Similar works

Full text

Available Versions

CiteSeerX