rationale.qbk 4.5 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122
  1. [/
  2. Copyright Oliver Kowalke 2013.
  3. Distributed under the Boost Software License, Version 1.0.
  4. (See accompanying file LICENSE_1_0.txt or copy at
  5. http://www.boost.org/LICENSE_1_0.txt
  6. ]
  7. [section:rationale Rationale]
  8. [heading preprocessor defines]
  9. [table preopcessor defines
  10. [[] []]
  11. [
  12. [BOOST_FIBERS_NO_ATOMICS]
  13. [no `std::atomic<>` used, inter-thread synchronization disabled]
  14. ]
  15. [
  16. [BOOST_FIBERS_SPINLOCK_STD_MUTEX]
  17. [use `std::mutex` as spinlock instead of default `XCHG`-sinlock with backoff]
  18. ]
  19. [
  20. [BOOST_FIBERS_SPIN_BACKOFF]
  21. [limit determines when to used `std::this_thread::yield()` instead of
  22. mnemonic `pause/yield` during busy wait (apllies on to `XCHG`-spinlock)]
  23. ]
  24. [
  25. [BOOST_FIBERS_SINGLE_CORE]
  26. [allways call `std::this_thread::yield()` without backoff during busy wait
  27. (apllies on to `XCHG`-spinlock)]
  28. ]
  29. ]
  30. [heading distinction between coroutines and fibers]
  31. The fiber library extends the coroutine library by adding a scheduler and
  32. synchronization mechanisms.
  33. * a coroutine yields
  34. * a fiber blocks
  35. When a coroutine yields, it passes control directly to its caller (or, in the
  36. case of symmetric coroutines, a designated other coroutine). When a fiber
  37. blocks, it implicitly passes control to the fiber scheduler. Coroutines have
  38. no scheduler because they need no scheduler.[footnote
  39. [@http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4024.pdf 'N4024:
  40. Distinguishing coroutines and fibers']].
  41. [heading what about transactional memory]
  42. GCC supports transactional memory since version 4.7. Unfortunately tests show
  43. that transactional memory is slower (ca. 4x) than spinlocks using atomics.
  44. Once transactional memory is improved (supporting hybrid tm), spinlocks will
  45. be replaced by __transaction_atomic{} statements surrounding the critical
  46. sections.
  47. [heading synchronization between fibers running in different threads]
  48. Synchronization classes from __boost_thread__ block the entire thread. In
  49. contrast, the synchronization classes from __boost_fiber__ block only specific
  50. fibers, so that the scheduler can still keep the thread busy running other
  51. fibers in the meantime.
  52. The synchronization classes from __boost_fiber__ are designed to be
  53. thread-safe, i.e. it is possible to synchronize fibers running in different
  54. threads as well as fibers running in the same thread. (However, there is a
  55. build option to disable cross-thread fiber synchronization support; see [link
  56. cross_thread_sync this description].)
  57. [#spurious_wakeup]
  58. [heading spurious wakeup]
  59. Spurious wakeup can happen when using
  60. [@http://en.cppreference.com/w/cpp/thread/condition_variable
  61. `std::condition_variable`]: the condition variable appears to be have been
  62. signaled while the awaited condition may still be false. Spurious wakeup can
  63. happen repeatedly and is caused on some multiprocessor systems where making
  64. `std::condition_variable` wakeup completely predictable would slow down all
  65. `std::condition_variable` operations.[footnote David R. Butenhof ["Programming
  66. with POSIX Threads]]
  67. __condition__ is not subject to spurious wakeup. Nonetheless it is
  68. prudent to test the business-logic condition in a `wait()` loop [mdash] or,
  69. equivalently, use one of the `wait( lock, predicate )` overloads.
  70. See also [link condition_variable_spurious_wakeups No Spurious Wakeups].
  71. [heading migrating fibers between threads]
  72. Support for migrating fibers between threads has been integrated. The
  73. user-defined scheduler must call __context_detach__ on a fiber-context on the
  74. source thread and __context_attach__ on the destination thread, passing the
  75. fiber-context to migrate. (For more information about custom schedulers, see
  76. [link custom Customization].)
  77. Examples `work_sharing` and `work_stealing` in directory `examples` might be
  78. used as a blueprint.
  79. See also [link migration Migrating fibers between threads].
  80. [heading support for Boost.Asio]
  81. Support for __boost_asio__[s] __async_result__ is not part of the official API.
  82. However, to integrate with a __io_service__, see [link integration Sharing a
  83. Thread with Another Main Loop]. To interface smoothly with an arbitrary Asio
  84. async I/O operation, see [link callbacks_asio Then There[s] __boost_asio__].
  85. [heading tested compilers]
  86. The library was tested with GCC-5.1.1, Clang-3.6.0 and MSVC-14.0 in c++11-mode.
  87. [heading supported architectures]
  88. __boost_fiber__ depends on __boost_context__ - the list of supported architectures
  89. can be found [@http://www.boost.org/doc/libs/release/libs/context/doc/html/context/architectures.html here].
  90. [endsect]