mirror of
https://github.com/boostorg/fiber.git
synced 2026-02-15 13:02:29 +00:00
91 lines
3.8 KiB
Plaintext
91 lines
3.8 KiB
Plaintext
[/
|
|
Copyright Oliver Kowalke 2013.
|
|
Distributed under the Boost Software License, Version 1.0.
|
|
(See accompanying file LICENSE_1_0.txt or copy at
|
|
http://www.boost.org/LICENSE_1_0.txt
|
|
]
|
|
|
|
[section:rationale Rationale]
|
|
|
|
[heading distinction between coroutines and fibers]
|
|
|
|
The fiber library extends the coroutine library by adding a scheduler and
|
|
synchronization mechanisms.
|
|
|
|
* a coroutine yields
|
|
* a fiber 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 fiber blocks, it implicitly passes control to the fiber scheduler.
|
|
Coroutines have no scheduler because they need no scheduler.
|
|
[footnote [@http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4024.pdf
|
|
'N4024: Distinguishing coroutines and fibers']].
|
|
|
|
|
|
[heading what about transactional memory]
|
|
|
|
GCC supports transactional memory since version 4.7. Unfortunately tests show
|
|
that transactional memory is slower (ca. 4x) than spinlocks using atomics.
|
|
Once transactional memory is improved (supporting hybrid tm), spinlocks will
|
|
be replaced by __transaction_atomic{} statements surrounding the critical
|
|
sections.
|
|
|
|
|
|
[heading synchronization between fibers running in different threads]
|
|
|
|
Synchronization classes from __boost_thread__ block the entire thread. In
|
|
contrast, the synchronization classes from __boost_fiber__ block only specific
|
|
fibers, so that the scheduler can still keep the thread busy running other
|
|
fibers in the meantime.
|
|
The synchronization classes from __boost_fiber__ are designed to be
|
|
thread-safe, i.e. it is possible to synchronize fibers running in different
|
|
threads as well as fibers running in the same thread. (However, there is a
|
|
build option to disable cross-thread fiber synchronization support; see [link
|
|
cross_thread_sync this description].)
|
|
|
|
|
|
[heading migrating fibers between threads]
|
|
|
|
Support for migrating fibers between threads was removed.
|
|
Especially in the case of NUMA-architectures, it is not always advisable to
|
|
migrate data between threads. Suppose fiber ['f] is running on logical CPU
|
|
['cpu0] which belongs to NUMA node ['node0]. The data of ['f] are allocated on
|
|
the physical memory located at ['node0]. Migrating the fiber from ['cpu0] to
|
|
another logical CPU ['cpuX] which is part of a different NUMA node ['nodeX]
|
|
will reduce the performance of the application because of increased latency of
|
|
memory access.
|
|
|
|
A more [*important] aspect is the problem with thread-local-storage ([*TLS]).
|
|
Instead of recomputing the address of a TLS variable, a compiler might, as an
|
|
optimization, cache its previously-computed address in various function stack
|
|
frames.[footnote dicussed in
|
|
[@http://www.crystalclearsoftware.com/soc/coroutine/coroutine/coroutine_thread.html
|
|
'Interaction between coroutines and threads' by Giovanni P. Deretta,
|
|
[@https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/3g6ZIWedGJ8
|
|
'A proposal to add coroutines to C++']]]
|
|
If a fiber was running on thread ['t0] and then migrated to thread ['t1], the
|
|
cached TLS variable address(es) would continue pointing to the TLS for thread
|
|
['t0]. Bad things would ensue.
|
|
|
|
[heading support for Boost.Asio]
|
|
|
|
Support for __boost_asio__'s __async_result__ is not part of the official API.
|
|
However, to integrate with a `boost::asio::io_service`, see [link integration
|
|
Sharing a Thread with Another Main Loop]. To interface smoothly with an
|
|
arbitrary Asio async I/O operation, see [link callbacks_asio Then There's
|
|
__boost_asio__].
|
|
|
|
[heading tested compilers]
|
|
|
|
The library was tested with GCC-4.9.2, GCC-5.1.1, Clang-3.6.0 and MSVC-14.0 in c++14-mode.
|
|
|
|
|
|
[heading supported architectures]
|
|
|
|
__boost_fiber__ depends on __boost_context__ - the list of supported architectures
|
|
can be found [@http://www.boost.org/doc/libs/release/libs/context/doc/html/context/architectures.html here].
|
|
|
|
|
|
[endsect]
|