boost/fiber
2
0
Fork 0
mirror of https://github.com/boostorg/fiber.git synced 2026-01-29 19:42:08 +00:00
Code Issues Projects Releases Wiki Activity

Review rationale.qbk.

Browse Source
This commit is contained in:
Nat Goodspeed
2015-08-14 11:21:42 -04:00
parent e08611555b
commit 666ada61ec
1 changed files with 16 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files

33
doc/rationale.qbk
View File

@@ -5,16 +5,15 @@
http://www.boost.org/LICENSE_1_0.txt
]
[section:rational Rational]
[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
* 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).
@@ -26,24 +25,24 @@ Coroutines have no scheduler because they need no scheduler.
[heading what about transactional memory]
GCC support transactional memory since version 4.7. Unfortunately testes showed
that transactional memory is slower (ca. 4x) than using spinlocks using atomics.
If transactional memory will be improved (supporting hybrid tm), spinlocks will
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.
sections.
[heading synchronization between fibers running in different threads]
Synchronization classes from __boost_thread__ do block the entire thread. In
contrast to this the synchronization classes from __boost_fiber__ do block only
the fiber, so that the thread is able to schedule and run other fibers in the
meantime.
The synchronization classes from __boost_fiber__ are designed to be thread-safe,
e.g. it is possible to synchronize fibers running in different schedulers
(different threads) or running in the same scheduler (same thread). (However,
there is a build option to disable that support; see [link cross_thread_sync
this description].)
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]