Executor.qbk 5.7 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141
  1. [/
  2. / Copyright (c) 2003-2019 Christopher M. Kohlhoff (chris at kohlhoff dot com)
  3. /
  4. / Distributed under the Boost Software License, Version 1.0. (See accompanying
  5. / file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
  6. /]
  7. [section:Executor1 Executor requirements]
  8. The library describes a standard set of requirements for ['executors]. A type
  9. meeting the `Executor` requirements embodies a set of rules for determining how
  10. submitted function objects are to be executed.
  11. A type `X` meets the `Executor` requirements if it satisfies the requirements of
  12. `CopyConstructible` (C++Std [copyconstructible]) and `Destructible` (C++Std
  13. [destructible]), as well as the additional requirements listed below.
  14. No constructor, comparison operator, copy operation, move operation, swap
  15. operation, or member functions `context`, `on_work_started`, and
  16. `on_work_finished` on these types shall exit via an exception.
  17. The executor copy constructor, comparison operators, and other member functions
  18. defined in these requirements shall not introduce data races as a result of
  19. concurrent calls to those functions from different threads.
  20. Let `ctx` be the execution context returned by the executor's `context()`
  21. member function. An executor becomes ['invalid] when the first call to
  22. `ctx.shutdown()` returns. The effect of calling `on_work_started`,
  23. `on_work_finished`, `dispatch`, `post`, or `defer` on an invalid executor is
  24. undefined. [inline_note The copy constructor, comparison operators, and
  25. `context()` member function continue to remain valid until `ctx` is destroyed.]
  26. In the table below, `x1` and `x2` denote (possibly const) values of type `X`,
  27. `mx1` denotes an xvalue of type `X`, `f` denotes a `MoveConstructible` (C++Std
  28. [moveconstructible]) function object callable with zero arguments, `a` denotes
  29. a (possibly const) value of type `A` meeting the `Allocator` requirements
  30. (C++Std [allocator.requirements]), and `u` denotes an identifier.
  31. [table Executor requirements
  32. [[expression] [type] [assertion/note\npre/post-conditions]]
  33. [
  34. [`X u(x1);`]
  35. []
  36. [Shall not exit via an exception.\n
  37. \n
  38. post: `u == x1` and
  39. `std::addressof(u.context()) == std::addressof(x1.context()).`]
  40. ]
  41. [
  42. [`X u(mx1);`]
  43. []
  44. [Shall not exit via an exception.\n
  45. \n
  46. post: `u` equals the prior value of `mx1` and
  47. `std::addressof(u.context())` equals the prior value of
  48. `std::addressof(mx1.context())`.]
  49. ]
  50. [
  51. [`x1 == x2`]
  52. [`bool`]
  53. [ Returns `true` only if `x1` and `x2` can be interchanged with identical
  54. effects in any of the expressions defined in these type requirements.
  55. [inline_note Returning `false` does not necessarily imply that the effects
  56. are not identical.]\n
  57. \n
  58. `operator==` shall be reflexive, symmetric, and transitive, and shall not
  59. exit via an exception.]
  60. ]
  61. [
  62. [`x1 != x2`]
  63. [`bool`]
  64. [Same as `!(x1 == x2)`.]
  65. ]
  66. [
  67. [`x1.context()`]
  68. [`execution_context&`, or `E&` where `E` is a type that satifisfies the
  69. [link boost_asio.reference.ExecutionContext `ExecutionContext`] requirements.]
  70. [Shall not exit via an exception.\n
  71. \n
  72. The comparison operators and member functions defined in these
  73. requirements shall not alter the reference returned by this function.]
  74. ]
  75. [
  76. [`x1.on_work_started()`]
  77. []
  78. [Shall not exit via an exception.]
  79. ]
  80. [
  81. [`x1.on_work_finished()`]
  82. []
  83. [Shall not exit via an exception.\n
  84. \n
  85. Precondition: A preceding call `x2.on_work_started()` where `x1 == x2`.]
  86. ]
  87. [
  88. [`x1.dispatch(std::move(f),a)`]
  89. []
  90. [Effects: Creates an object `f1` initialized with
  91. [^['DECAY_COPY]]`(forward<Func>(f))` (C++Std \[thread.decaycopy\]) in the
  92. current thread of execution . Calls `f1()` at most once. The executor may
  93. block forward progress of the caller until `f1()` finishes execution.\n
  94. \n
  95. Executor implementations should use the supplied allocator to allocate any
  96. memory required to store the function object. Prior to invoking the
  97. function object, the executor shall deallocate any memory allocated.
  98. [inline_note Executors defined in this Technical Specification always use
  99. the supplied allocator unless otherwise specified.]\n
  100. \n
  101. Synchronization: The invocation of `dispatch` synchronizes with (C++Std
  102. \[intro.multithread\]) the invocation of `f1`.]
  103. ]
  104. [
  105. [`x1.post(std::move(f),a)`\n
  106. `x1.defer(std::move(f),a)`]
  107. []
  108. [Effects: Creates an object `f1` initialized with
  109. [^['DECAY_COPY]]`(forward<Func>(f))` in the current thread of execution.
  110. Calls `f1()` at most once. The executor shall not block forward progress
  111. of the caller pending completion of `f1()`.\n
  112. \n
  113. Executor implementations should use the supplied allocator to allocate any
  114. memory required to store the function object. Prior to invoking the
  115. function object, the executor shall deallocate any memory allocated.
  116. [inline_note Executors defined in this Technical Specification always use
  117. the supplied allocator unless otherwise specified.]\n
  118. \n
  119. Synchronization: The invocation of `post` or `defer` synchronizes with
  120. (C++Std \[intro.multithread\]) the invocation of `f1`.\n
  121. \n
  122. [inline_note Although the requirements placed on `defer` are identical to
  123. `post`, the use of `post` conveys a preference that the caller ['does not]
  124. block the first step of [^f1]'s progress, whereas `defer` conveys a
  125. preference that the caller ['does] block the first step of [^f1]. One use
  126. of `defer` is to convey the intention of the caller that [^f1] is a
  127. continuation of the current call context. The executor may use this
  128. information to optimize or otherwise adjust the way in which `f1` is
  129. invoked.]]
  130. ]
  131. ]
  132. [endsect]