Re: [Boost-users] [boost] Boost.Fiber mini-review September 4-13

Subject: Re: [Boost-users] [boost] Boost.Fiber mini-review September 4-13
From: Oliver Kowalke (oliver.kowalke_at_[hidden])
Date: 2015-09-06 04:51:31

2015-09-05 4:26 GMT+02:00 Oliver Kowalke <oliver.kowalke_at_[hidden]>:

> 2015-09-04 23:08 GMT+02:00 Vicente J. Botet Escriba <
> vicente.botet_at_[hidden]>:
>
> Oliver, is there something in the documentation that refers to each one of
>> the points that must be covered?
>>
>
> you refer to the issues of the last review?
> I did not add the list to the boost.fiber documentation
>

requested was

provide performance tests:
- create, join, detach, yield fiber
- wait on future
- create on join several fibers
- cost of thread safety (atomics)

improve documentation

- rationale page explaining what's there, what's not and why
- explain distinction between Coroutine library and Fiber library
- a section on how to install and run the tests and examples. The need
to embed in a Boost tree is implied but not stated. Mention the need
to build the library and link with it.
- explain synchronization between fibers on different threads. Must
the code take more care with this than with synchronizing fibers on
the same thread?
- clarify that an exception raised by a fiber function calls
std::terminate(), as with std::thread, rather than being consumed
- clarify thread-local effect of set_scheduling_algorithm(). There was
a request to put this function in a this_thread nested namespace to
further clarify
- Move algorithm class documentation to "Extension" or "Customization"
section. Clarify that it's not part of the baseline library
functionality, but a customization point.
- Document fiber::id.
- Better document promise/future for void and R& (per C++ standard).
- Document thread safety of each support class (or method, if it
varies by method).
- Document complexity guarantees per API.
- Document exception safety per API.
- Document supported architectures (perhaps link to Coroutine
library's list); state minimum compiler versions.
- Document the library's ASIO support. Link to Coroutine's ASIO yield
functionality; ensure that ASIO yield is adequately explained. In
particular, distinguish it from this_fiber::yield.
- Better explain (and/or comment) publish-subscribe example, also
other existing examples.
In addition to the documentation requests above, there were requests
for additional examples:
- Simple example of ASIO callback implementation vs. the same logic
using Fiber's ASIO support, a la [4].
- Example of a fiber pool.
- Example of an arbitrary thread B filling a future on which a fiber
in thread A is waiting.
- Example of an arbitrary thread B posting to an asio::io_service
running fibers in thread A.
- Either defend fibers::condition_variable from spurious wakeups in
existing examples, OR document the stronger condition_variable
guarantee.
- Example of M:N threading with ASIO. That might involve either one
io_service per CPU, with fiber migration; or a single io_service with
run() calls from each CPU, grouping fibers for each CPU into strands.
- Example of one thread with many fibers making service requests on a
pool of worker threads performing blocking calls.
- Example of using thread_specific_ptr to manage lifespan of
user-specified scheduler.
- Example of the owner of a fiber changing the fiber's thread affinity
vs. the fiber itself. When would you use each tactic?
- Load example programs into an Examples appendix so that Google
searches can turn up library documentation.

API

- Allocating a default scheduler object, rather than specifying a
default template param, was praised.
- Three people called out the set difference between Boost.Thread
features and Fiber (e.g. future::get_exception_ptr()). One wants these
implemented immediately; another says they can be added later; the
third simply requests that they be documented, with rationale.
- Two people frowned on introducing operator bool methods not found in
std::thread or Boost.Thread.
- C++11 support was mentioned, notably Boost macros such as
BOOST_RV_REF and BOOST_EXPLICIT_OPERATOR_BOOL. Also mentioned were:
C++11 idioms; C++11 std::thread patterns; move construction;
initializer lists; rvalue this overloads; deleting operators.
- The fiber constructor and async() should accept a move-only callable.
- At least for a C++11 compiler, fiber constructor and async() should
accept variadic parameters. These should support move-only types, like
Boost.Thread. C++03 support for variadic parameters would be nice, but
is less important.
- Every API involving time point or duration should accept arbitrary
clock types, immediately converting to a canonical duration type for
internal use.
- Queues should support value_pop() returning item by value. This
supports an item type without a default constructor.
- Nested scoped_lock typedef has been deprecated in thread library.
Remove in Fiber library.
- Align the return type of shared_future::get() with the standard. In
general, ensure that parameter types and return types are aligned with
the standard.
- A couple of people were bothered by the use of types in the detail
namespace as parameters or return values in the algorithm API. (I
note, however, that extending e.g. Boost.Range can involve touching
its detail namespace. A customization point for a library may be a bit
of a gray area.)
- There was a suggestion to rename algorithm to scheduler. In that
case, presumably set_scheduling_algorithm() could be renamed
set_scheduler().
- There was a request to rename round_robin_ws to
round_robin_work_stealing.
- A couple of people consider the algorithm API too monolithic,
pointing to redundancies in the round_robin, round_robin_ws and asio
round_robin implementations. They suggested teasing out distinct
classes, so that (for instance) a user-coded scheduler might be able
to override a single method to respect fiber priority. In fact Eugene
Yakubovich offered to experiment with refactoring the algorithm class
this way.
- There was a request for set_scheduling_algorithm() to return the
previous pointer. (It might be useful for the requester to explain the
anticipated use case. An earlier iteration of
set_scheduling_algorithm() did return the previous pointer; Oliver
intentionally changed that behavior.)
- fiber_group got one thumbs-up and two thumbs-down. Options: retain;
improve to use move support rather than fiber*; discard. There is an
opportunity to improve on thread_group; naturally there is risk in
diverging from thread_group.
- Request deferred futures for lazy evaluation.
- There was a suggestion to introduce a global object to coordinate
thread-specific fiber schedulers, in the hope that the global object
could perform all relevant locking and the thread-specific fiber
schedulers could themselves be thread-unsafe.
- There was a request to unify steal_from() and migrate_to() into a
single method. I infer that this is predicated on the previous
suggestion.
- Request future::then() et al, per [5]. (Someone please clarify the
present status of N3784?)
- Request enriched barrier support per [6] and [7]. (Someone please
clarify the present status of N3817?)
- There are two fiber properties specific to particular schedulers:
thread_affinity (used only by round_robin_ws) and priority (as yet
unused by any scheduler). What if a user-coded scheduler requires a
fiber property that does not yet exist? Is there a general approach
that could subsume the present support for thread_affinity and
priority, in fiber and this_fiber? Could the initial values for such
properties be passed as part of the fiber constructor's attributes
parameter?
- One use case was surfaced that may engage the previous bullet: the
desire to associate a given fiber with any of a group of threads, such
as the set of threads local to a NUMA domain or physical CPU.

IMPLEMENTATION

- Replace std::auto_ptr with boost::scoped_ptr. The former produces
deprecation warnings on GCC.
- Reduce redundancy between try_lock() and lock().
- boost::fibers::asio::detail::yield_handler::operator()() calls
algorithm::spawn() before algorithm::run(). Does this allow the
scheduler to choose the next fiber to run, e.g. a user-coded scheduler
that respects fiber priority?
- Add memory transaction support to spinlock a la [8].
- Intel TSX lock avoidance would be nice.