mirror of
https://github.com/boostorg/fiber.git
synced 2026-02-20 02:32:19 +00:00
77 lines
2.9 KiB
Plaintext
77 lines
2.9 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 has been integrated.
|
|
The users-defined scheduler has to call `context::migrate()` with
|
|
the migrated fiber-context as argument (see [link custom Customization];
|
|
examles ` work_sharing` and `work_stealing` in directory `examples`
|
|
might be used as a blue-print).
|
|
|
|
|
|
[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]
|