| Home | Libraries | People | FAQ | More

#### Class pooled_fixedsize_stack

Boost.Fiber provides the class `pooled_fixedsize_stack` which models the stack-allocator concept. In contrast to `protected_fixedsize_stack` it does not append a guard page at the end of each stack. The memory is managed internally by `boost::pool<>`.

    #include <boost/fiber/pooled_fixedsize_stack.hpp>

    struct pooled_fixedsize_stack {
        pooled_fixedsize_stack(std::size_t stack_size = traits_type::default_size(), std::size_t next_size = 32, std::size_t max_size = 0);

        stack_context allocate();

        void deallocate( stack_context &);
    }

###### `pooled_fixedsize_stack(std::size_t stack_size, std::size_t next_size, std::size_t max_size)`

Preconditions:

  `traits_type::is_unbounded() || ( traits_type::maximum_size() >= stack_size)` and `0 < next_size`.

Effects:

  Allocates memory of at least `stack_size` bytes and stores a pointer to the stack and its actual size in `sctx`. Depending on the architecture (the stack grows downwards/upwards) the stored address is the highest/lowest address of the stack. Argument `next_size` determines the number of stacks to request from the system the first time that `*this` needs to allocate system memory. The third argument `max_size` controls how much memory might be allocated for stacks — a value of zero means no upper limit.

###### `stack_context allocate()`

Preconditions:

  `traits_type::is_unbounded() || ( traits_type::maximum_size() >= stack_size)`.

Effects:

  Allocates memory of at least `stack_size` bytes and stores a pointer to the stack and its actual size in `sctx`. Depending on the architecture (the stack grows downwards/upwards) the stored address is the highest/lowest address of the stack.

###### `void deallocate( stack_context & sctx)`

Preconditions:

  `sctx.sp` is valid, `traits_type::is_unbounded() || ( traits_type::maximum_size() >= sctx.size)`.

Effects:

  Deallocates the stack space.

##### Class fixedsize_stack

Boost.Fiber provides the class __fixedsize__ which models the stack-allocator concept. In contrast to __protected_fixedsize__ it does not append a guard page at the end of each stack. The memory is simply managed by `std::malloc()` and `std::free()`.

    #include <boost/context/fixedsize_stack.hpp>

    struct fixedsize_stack {
        fixedsize_stack(std::size_t size = traits_type::default_size());

        stack_context allocate();

        void deallocate( stack_context &);
    }

###### `stack_context allocate()`

Preconditions:

  `traits_type::minimum_size() <= size` and `traits_type::is_unbounded() || ( traits_type::maximum_size() >= size)`.

Effects:

  Allocates memory of at least `size` bytes and stores a pointer to the stack and its actual size in `sctx`. Depending on the architecture (the stack grows downwards/upwards) the stored address is the highest/lowest address of the stack.

###### `void deallocate( stack_context & sctx)`

Preconditions:

  `sctx.sp` is valid, `traits_type::minimum_size() <= sctx.size` and `traits_type::is_unbounded() || ( traits_type::maximum_size() >= sctx.size)`.

Effects:

  Deallocates the stack space.

##### Class segmented_stack

Boost.Fiber supports usage of a `segmented_stack`, i.e. the stack grows on demand. The fiber is created with a minimal stack size which will be increased as required. Class `segmented_stack` models the stack-allocator concept. In contrast to `protected_fixedsize_stack` and `fixedsize_stack` it creates a stack which grows on demand.

| Note
Segmented stacks are currently only supported by gcc from version 4.7 and clang from version 3.4 onwards. In order to use a `segmented_stack` Boost.Fiber must be built with property `segmented-stacks`, e.g. toolset=gcc segmented-stacks=on at b2/bjam command line.

    #include <boost/fiber/segmented_stack.hpp>

    struct segmented_stack {
        segmented_stack(std::size_t stack_size = traits_type::default_size());

        stack_context allocate();

        void deallocate( stack_context &);
    }

###### `stack_context allocate()`

Preconditions:

  `traits_type::minimum_size() <= size` and `traits_type::is_unbounded() || ( traits_type::maximum_size() >= size)`.

Effects:

  Allocates memory of at least `size` bytes and stores a pointer to the stack and its actual size in `sctx`. Depending on the architecture (the stack grows downwards/upwards) the stored address is the highest/lowest address of the stack.

###### `void deallocate( stack_context & sctx)`

Preconditions:

  `sctx.sp` is valid, `traits_type::minimum_size() <= sctx.size` and `traits_type::is_unbounded() || ( traits_type::maximum_size() >= sctx.size)`.

Effects:

  Deallocates the stack space.

| Note
If the library is compiled for segmented stacks, `segmented_stack` is the only available stack allocator.

##### Synchronization

In general, Boost.Fiber synchronization objects can neither be moved nor copied. A synchronization object acts as a mutually-agreed rendezvous point between different fibers. If such an object were copied somewhere else, the new copy would have no consumers. If such an object were moved somewhere else, leaving the original instance in an unspecified state, existing consumers would behave strangely.

The fiber synchronization objects provided by this library will, by default, safely synchronize fibers running on different threads. However, this level of synchronization can be removed (for performance) by building the library with `BOOST_FIBERS_NO_ATOMICS` defined. When the library is built with that macro, you must ensure that all the fibers referencing a particular synchronization object are running in the same thread.

###### Mutex Types

##### Class `mutex`

    #include <boost/fiber/mutex.hpp>

    class mutex {
    public:
        mutex();
        ~mutex();

        mutex( mutex const& other) = delete;
        mutex & operator=( mutex const& other) = delete;

        void lock();
        bool try_lock();
        void unlock();
    };

`mutex` provides an exclusive-ownership mutex. At most one fiber can own the lock on a given instance of `mutex` at any time. Multiple concurrent calls to `lock()`, `try_lock()` and `unlock()` shall be permitted.

Any fiber blocked in `lock()` is suspended until the owning fiber releases the lock by calling `unlock()`.

##### Member function `lock`()

    void lock();

Precondition:

  The calling fiber doesn't own the mutex.

Effects:

  The current fiber blocks until ownership can be obtained.

Throws:

  `lock_error`

Error Conditions:

  resource_deadlock_would_occur: if `boost::this_fiber::get_id()` already owns the mutex.

##### Member function `try_lock`()

    bool try_lock();

Precondition:

  The calling fiber doesn't own the mutex.

Effects:

  Attempt to obtain ownership for the current fiber without blocking.

Returns:

  `true` if ownership was obtained for the current fiber, `false` otherwise.

Throws:

  `lock_error`

Error Conditions:

  resource_deadlock_would_occur: if `boost::this_fiber::get_id()` already owns the mutex.

##### Member function `unlock`()

    void unlock();

Precondition:

  The current fiber owns `*this`.

Effects:

  Releases a lock on `*this` by the current fiber.

Throws:

  `lock_error`

Error Conditions:

  operation_not_permitted: if `boost::this_fiber::get_id()` does not own the mutex.

##### Class `timed_mutex`

    #include <boost/fiber/timed_mutex.hpp>

    class timed_mutex {
    public:
        timed_mutex();
        ~timed_mutex();

        timed_mutex( timed_mutex const& other) = delete;
        timed_mutex & operator=( timed_mutex const& other) = delete;

        void lock();
        bool try_lock();
        void unlock();

        template< typename Clock, typename Duration >
        bool try_lock_until( std::chrono::time_point< Clock, Duration > const& timeout_time);
        template< typename Rep, typename Period >
        bool try_lock_for( std::chrono::duration< Rep, Period > const& timeout_duration);
    };

`timed_mutex` provides an exclusive-ownership mutex. At most one fiber can own the lock on a given instance of `timed_mutex` at any time. Multiple concurrent calls to `lock()`, `try_lock()`, `try_lock_until()`, `try_lock_for()` and `unlock()` shall be permitted.

##### Member function `lock`()

    void lock();

Precondition:

  The calling fiber doesn't own the mutex.

Effects:

  The current fiber blocks until ownership can be obtained.

Throws:

  `lock_error`

Error Conditions:

  resource_deadlock_would_occur: if `boost::this_fiber::get_id()` already owns the mutex.

##### Member function `try_lock`()

    bool try_lock();

Precondition:

  The calling fiber doesn't own the mutex.

Effects:

  Attempt to obtain ownership for the current fiber without blocking.

Returns:

  `true` if ownership was obtained for the current fiber, `false` otherwise.

Throws:

  `lock_error`

Error Conditions:

  resource_deadlock_would_occur: if `boost::this_fiber::get_id()` already owns the mutex.

##### Member function `unlock`()

    void unlock();

Precondition:

  The current fiber owns `*this`.

Effects:

  Releases a lock on `*this` by the current fiber.

Throws:

  `lock_error`

Error Conditions:

  operation_not_permitted: if `boost::this_fiber::get_id()` does not own the mutex.

##### Templated member function `try_lock_until`()

    template< typename Clock, typename Duration >
    bool try_lock_until( std::chrono::time_point< Clock, Duration > const& timeout_time);

Precondition:

  The calling fiber doesn't own the mutex.

Effects:

  Attempt to obtain ownership for the current fiber. Blocks until ownership can be obtained, or the specified time is reached. If the specified time has already passed, behaves as `timed_mutex::try_lock()`.

Returns:

  `true` if ownership was obtained for the current fiber, `false` otherwise.

Throws:

  `lock_error`, timeout-related exceptions.

Error Conditions:

  resource_deadlock_would_occur: if `boost::this_fiber::get_id()` already owns the mutex.

##### Templated member function `try_lock_for`()

    template< typename Rep, typename Period >
    bool try_lock_for( std::chrono::duration< Rep, Period > const& timeout_duration);

Precondition:

  The calling fiber doesn't own the mutex.

Effects:

  Attempt to obtain ownership for the current fiber. Blocks until ownership can be obtained, or the specified time is reached. If the specified time has already passed, behaves as `timed_mutex::try_lock()`.

Returns:

  `true` if ownership was obtained for the current fiber, `false` otherwise.

Throws:

  `lock_error`, timeout-related exceptions.

Error Conditions:

  resource_deadlock_would_occur: if `boost::this_fiber::get_id()` already owns the mutex.

##### Class `recursive_mutex`

    #include <boost/fiber/recursive_mutex.hpp>

    class recursive_mutex {
    public:
        recursive_mutex();
        ~recursive_mutex();

        recursive_mutex( recursive_mutex const& other) = delete;
        recursive_mutex & operator=( recursive_mutex const& other) = delete;

        void lock();
        bool try_lock() noexcept;
        void unlock();
    };

`recursive_mutex` provides an exclusive-ownership recursive mutex. At most one fiber can own the lock on a given instance of `recursive_mutex` at any time. Multiple concurrent calls to `lock()`, `try_lock()` and `unlock()` shall be permitted. A fiber that already has exclusive ownership of a given `recursive_mutex` instance can call `lock()` or `try_lock()` to acquire an additional level of ownership of the mutex. `unlock()` must be called once for each level of ownership acquired by a single fiber before ownership can be acquired by another fiber.

##### Member function `lock`()

    void lock();

Effects:

  The current fiber blocks until ownership can be obtained.

Throws:

  `fiber_interrupted`

##### Member function `try_lock`()

    bool try_lock() noexcept;

Effects:

  Attempt to obtain ownership for the current fiber without blocking.

Returns:

  `true` if ownership was obtained for the current fiber, `false` otherwise.

Throws:

  Nothing.

##### Member function `unlock`()

    void unlock();

Effects:

  Releases a lock on `*this` by the current fiber.

Throws:

  `lock_error`

Error Conditions:

  operation_not_permitted: if `boost::this_fiber::get_id()` does not own the mutex.

##### Class `recursive_timed_mutex`

    #include <boost/fiber/recursive_timed_mutex.hpp>

    class recursive_timed_mutex {
    public:
        recursive_timed_mutex();
        ~recursive_timed_mutex();

        recursive_timed_mutex( recursive_timed_mutex const& other) = delete;
        recursive_timed_mutex & operator=( recursive_timed_mutex const& other) = delete;

        void lock();
        bool try_lock() noexcept;
        void unlock();

        template< typename Clock, typename Duration >
        bool try_lock_until( std::chrono::time_point< Clock, Duration > const& timeout_time);
        template< typename Rep, typename Period >
        bool try_lock_for( std::chrono::duration< Rep, Period > const& timeout_duration);
    };

`recursive_timed_mutex` provides an exclusive-ownership recursive mutex. At most one fiber can own the lock on a given instance of `recursive_timed_mutex` at any time. Multiple concurrent calls to `lock()`, `try_lock()`, `try_lock_for()`, `try_lock_until()` and `unlock()` shall be permitted. A fiber that already has exclusive ownership of a given `recursive_timed_mutex` instance can call `lock()`, `try_lock()`, `try_lock_for()` or `try_lock_until()` to acquire an additional level of ownership of the mutex. `unlock()` must be called once for each level of ownership acquired by a single fiber before ownership can be acquired by another fiber.

##### Member function `lock`()

    void lock();

Effects:

  The current fiber blocks until ownership can be obtained.

Throws:

  `fiber_interrupted`

##### Member function `try_lock`()

    bool try_lock() noexcept;

Effects:

  Attempt to obtain ownership for the current fiber without blocking.

Returns:

  `true` if ownership was obtained for the current fiber, `false` otherwise.

Throws:

  Nothing.

##### Member function `unlock`()

    void unlock();

Effects:

  Releases a lock on `*this` by the current fiber.

Throws:

  `lock_error`

Error Conditions:

  operation_not_permitted: if `boost::this_fiber::get_id()` does not own the mutex.

##### Templated member function `try_lock_until`()

    template< typename Clock, typename Duration >
    bool try_lock_until( std::chrono::time_point< Clock, Duration > const& timeout_time);

Effects:

  Attempt to obtain ownership for the current fiber. Blocks until ownership can be obtained, or the specified time is reached. If the specified time has already passed, behaves as `recursive_timed_mutex::try_lock()`.

Returns:

  `true` if ownership was obtained for the current fiber, `false` otherwise.

Throws:

  Timeout-related exceptions.

##### Templated member function `try_lock_for`()

    template< typename Rep, typename Period >
    bool try_lock_for( std::chrono::duration< Rep, Period > const& timeout_duration);

Effects:

  Attempt to obtain ownership for the current fiber. Blocks until ownership can be obtained, or the specified time is reached. If the specified time has already passed, behaves as `recursive_timed_mutex::try_lock()`.

Returns:

  `true` if ownership was obtained for the current fiber, `false` otherwise.

Throws:

  Timeout-related exceptions.

###### Condition Variables

Synopsis

    enum class cv_status; {
        no_timeout,
        timeout
    };

    class condition_variable;
    class condition_variable_any;

The class `condition_variable` provides a mechanism for a fiber to wait for notification from another fiber. When the fiber awakens from the wait, then it checks to see if the appropriate condition is now true, and continues if so. If the condition is not true, then the fiber calls `wait` again to resume waiting. In the simplest case, this condition is just a boolean variable:

    boost::fibers::condition_variable cond;
    boost::fibers::mutex mtx;
    bool data_ready = false;

    void process_data();

    void wait_for_data_to_process() {
        {
            std::unique_lock< boost::fibers::mutex > lk( mtx);
            while ( ! data_ready) {
                cond.wait( lk);
            }
        }   // release lk
        process_data();
    }

Notice that the `lk` is passed to `condition_variable::wait()`: `wait()` will atomically add the fiber to the set of fibers waiting on the condition variable, and unlock the `mutex`. When the fiber is awakened, the `mutex` will be locked again before the call to `wait()` returns. This allows other fibers to acquire the `mutex` in order to update the shared data, and ensures that the data associated with the condition is correctly synchronized.

`wait_for_data_to_process()` could equivalently be written:

    void wait_for_data_to_process() {
        {
            std::unique_lock< boost::fibers::mutex > lk( mtx);
            // make condition_variable::wait() perform the loop
            cond.wait( lk, [](){ return data_ready; });
        }   // release lk
        process_data();
    }

In the meantime, another fiber sets `data_ready` to `true`, and then calls either `condition_variable::notify_one()` or `condition_variable::notify_all()` on the `condition_variable` `cond` to wake one waiting fiber or all the waiting fibers respectively.

    void retrieve_data();
    void prepare_data();

    void prepare_data_for_processing() {
        retrieve_data();
        prepare_data();
        {
            std::unique_lock< boost::fibers::mutex > lk( mtx);
            data_ready = true;
        }
        cond.notify_one();
    }

Note that the same `mutex` is locked before the shared data is updated, but that the `mutex` does not have to be locked across the call to `condition_variable::notify_one()`.

Locking is important because the synchronization objects provided by Boost.Fiber can be used to synchronize fibers running on different threads.

Boost.Fiber provides both `condition_variable` and `condition_variable_any`. `boost::fibers::condition_variable` can only wait on `std::unique_lock``< boost::fibers::` `mutex``>` while `boost::fibers::condition_variable_any` can wait on user-defined lock types.

No Spurious Wakeups

Neither `condition_variable` nor `condition_variable_any` are subject to spurious wakeup: `condition_variable::wait()` can only wake up when `condition_variable::notify_one()` or `condition_variable::notify_all()` is called. Even so, it is prudent to use one of the `wait( lock, predicate )` overloads.

Consider a set of consumer fibers processing items from a `std::queue`. The queue is continually populated by a set of producer fibers.

The consumer fibers might reasonably wait on a `condition_variable` as long as the queue remains `empty()`.

Because producer fibers might `push()` items to the queue in bursts, they call `condition_variable::notify_all()` rather than `condition_variable::notify_one()`.

But a given consumer fiber might well wake up from `condition_variable::wait()` and find the queue `empty()`, because other consumer fibers might already have processed all pending items.

(See also spurious wakeup.)

Enumeration `cv_status`

A timed wait operation might return because of timeout or not.

    enum class cv_status {
        no_timeout,
        timeout
    };

`no_timeout`

Effects:

  The condition variable was awakened with `notify_one` or `notify_all`.

`timeout`

Effects:

  The condition variable was awakened by timeout.

##### Class `condition_variable_any`

    #include <boost/fiber/condition_variable.hpp>

    class condition_variable_any {
    public:
        condition_variable_any();
        ~condition_variable_any();

        condition_variable_any( condition_variable_any const&) = delete;
        condition_variable_any & operator=( condition_variable_any const&) = delete;

        void notify_one() noexcept;
        void notify_all() noexcept;

        template< typename LockType >
        void wait( LockType &);

        template< typename LockType, typename Pred >
        void wait( LockType &, Pred);

        template< typename LockType, typename Clock, typename Duration >
        cv_status wait_until( LockType &,
                              std::chrono::time_point< Clock, Duration > const&);

        template< typename LockType, typename Clock, typename Duration, typename Pred >
        bool wait_until( LockType &,
                         std::chrono::time_point< Clock, Duration > const&,
                         Pred);

        template< typename LockType, typename Rep, typename Period >
        cv_status wait_for( LockType &,
                            std::chrono::duration< Rep, Period > const&);

        template< typename LockType, typename Rep, typename Period, typename Pred >
        bool wait_for( LockType &,
                       std::chrono::duration< Rep, Period > const&,
                       Pred);
    };

Constructor

    condition_variable_any()

Effects:

  Creates the object.

Throws:

  Nothing.

Destructor

    ~condition_variable_any()

Precondition:

  All fibers waiting on `*this` have been notified by a call to `notify_one` or `notify_all` (though the respective calls to `wait`, `wait_for` or `wait_until` need not have returned).

Effects:

  Destroys the object.

##### Member function `notify_one`()

    void notify_one() noexcept;

Effects:

  If any fibers are currently blocked waiting on `*this` in a call to `wait`, `wait_for` or `wait_until`, unblocks one of those fibers.

Throws:

  Nothing.

Note:

  It is arbitrary which waiting fiber is resumed.

##### Member function `notify_all`()

    void notify_all() noexcept;

Effects:

  If any fibers are currently blocked waiting on `*this` in a call to `wait`, `wait_for` or `wait_until`, unblocks all of those fibers.

Throws:

  Nothing.

Note:

  This is why a waiting fiber must also check for the desired program state using a mechanism external to the `condition_variable_any`, and retry the wait until that state is reached. A fiber waiting on a `condition_variable_any` might well wake up a number of times before the desired state is reached.

##### Templated member function `wait`()

    template< typename LockType >
        void wait( LockType & lk);

    template< typename LockType, typename Pred >
    void wait( LockType & lk, Pred pred);

Precondition:

  `lk` is locked by the current fiber, and either no other fiber is currently waiting on `*this`, or the execution of the `mutex()` member function on the `lk` objects supplied in the calls to `wait` in all the fibers currently waiting on `*this` would return the same value as `lk->mutex()` for this call to `wait`.

Effects:

  Atomically call `lk.unlock()` and blocks the current fiber. The fiber will unblock when notified by a call to `this->notify_one()` or `this->notify_all()`. When the fiber is unblocked (for whatever reason), the lock is reacquired by invoking `lk.lock()` before the call to `wait` returns. The lock is also reacquired by invoking `lk.lock()` if the function exits with an exception. The member function accepting `pred` is shorthand for:

      while ( ! pred() ) {
          wait( lk);
      }

Postcondition:

  `lk` is locked by the current fiber.

Throws:

  `fiber_error` if an error occurs, `fiber_interrupted` if the wait was interrupted by a call to `fiber::interrupt()` on the `fiber` object associated with the current fiber of execution.

Note:

  The Precondition is a bit dense. It merely states that all the fibers concurrently calling `wait` on `*this` must wait on `lk` objects governing the same `mutex`. Three distinct objects are involved in any `condition_variable_any::wait()` call: the `condition_variable_any` itself, the `mutex` coordinating access between fibers and a local lock object (e.g. `std::unique_lock`). In general, you can partition the lifespan of a given `condition_variable_any` instance into periods with one or more fibers waiting on it, separated by periods when no fibers are waiting on it. When more than one fiber is waiting on that `condition_variable_any`, all must pass lock objects referencing the same `mutex` instance.

##### Templated member function `wait_until`()

    template< typename LockType, typename Clock, typename Duration >
    cv_status wait_until( LockType & lk,
                          std::chrono::time_point< Clock, Duration > const& abs_time);

    template< typename LockType, typename Clock, typename Duration, typename Pred >
    bool wait_until( LockType & lk,
                     std::chrono::time_point< Clock, Duration > const& abs_time,
                     Pred pred);

Precondition:

  `lk` is locked by the current fiber, and either no other fiber is currently waiting on `*this`, or the execution of the `mutex()` member function on the `lk` objects supplied in the calls to `wait`, `wait_for` or `wait_until` in all the fibers currently waiting on `*this` would return the same value as `lk.mutex()` for this call to `wait_until`.

Effects:

  Atomically call `lk.unlock()` and blocks the current fiber. The fiber will unblock when notified by a call to `this->notify_one()` or `this->notify_all()`, when the system time would be equal to or later than the specified `abs_time`. When the fiber is unblocked (for whatever reason), the lock is reacquired by invoking `lk.lock()` before the call to `wait_until` returns. The lock is also reacquired by invoking `lk.lock()` if the function exits with an exception. The member function accepting `pred` is shorthand for:

      while ( ! pred() ) {
          if ( cv_status::timeout == wait_until( lk, abs_time) )
              return pred();
      }
      return true;

  That is, even if `wait_until()` times out, it can still return `true` if `pred()` returns `true` at that time.

Postcondition:

  `lk` is locked by the current fiber.

Throws:

  `fiber_error` if an error occurs, `fiber_interrupted` if the wait was interrupted by a call to `fiber::interrupt()` on the `fiber` object associated with the current fiber of execution or timeout-related exceptions.

Returns:

  The overload without `pred` returns `cv_status::no_timeout` if awakened by `notify_one()` or `notify_all()`, or `cv_status::timeout` if awakened because the system time is past `abs_time`.

Returns:

  The overload accepting `pred` returns `false` if the call is returning because the time specified by `abs_time` was reached and the predicate returns `false`, `true` otherwise.

Note:

  See Note for `condition_variable_any::wait()`.

##### Templated member function `wait_for`()

    template< typename LockType, typename Rep, typename Period >
    cv_status wait_for( LockType & lk,
                        std::chrono::duration< Rep, Period > const& rel_time);

    template< typename LockType, typename Rep, typename Period, typename Pred >
    bool wait_for( LockType & lk,
                   std::chrono::duration< Rep, Period > const& rel_time,
                   Pred pred);

Precondition:

  `lk` is locked by the current fiber, and either no other fiber is currently waiting on `*this`, or the execution of the `mutex()` member function on the `lk` objects supplied in the calls to `wait`, `wait_for` or `wait_until` in all the fibers currently waiting on `*this` would return the same value as `lk.mutex()` for this call to `wait_for`.

Effects:

  Atomically call `lk.unlock()` and blocks the current fiber. The fiber will unblock when notified by a call to `this->notify_one()` or `this->notify_all()`, when a time interval equal to or greater than the specified `rel_time` has elapsed. When the fiber is unblocked (for whatever reason), the lock is reacquired by invoking `lk.lock()` before the call to `wait` returns. The lock is also reacquired by invoking `lk.lock()` if the function exits with an exception. The `wait_for()` member function accepting `pred` is shorthand for:

      while ( ! pred() ) {
          if ( cv_status::timeout == wait_for( lk, rel_time) ) {
              return pred();
          }
      }
      return true;

  (except of course that `rel_time` is adjusted for each iteration). The point is that, even if `wait_for()` times out, it can still return `true` if `pred()` returns `true` at that time.

Postcondition:

  `lk` is locked by the current fiber.

Throws:

  `fiber_error` if an error occurs, `fiber_interrupted` if the wait was interrupted by a call to `fiber::interrupt()` on the `fiber` object associated with the current fiber of execution or timeout-related exceptions.

Returns:

  The overload without `pred` returns `cv_status::no_timeout` if awakened by `notify_one()` or `notify_all()`, or `cv_status::timeout` if awakened because at least `rel_time` has elapsed.

Returns:

  The overload accepting `pred` returns `false` if the call is returning because at least `rel_time` has elapsed and the predicate returns `false`, `true` otherwise.

Note:

  See Note for `condition_variable_any::wait()`.

##### Class `condition_variable`

    #include <boost/fiber/condition_variable.hpp>

    class condition_variable {
    public:
        condition_variable();
        ~condition_variable();

        condition_variable( condition_variable const&) = delete;
        condition_variable & operator=( condition_variable const&) = delete;

        void notify_one() noexcept;
        void notify_all() noexcept;

        void wait( std::unique_lock< mutex > &);

        template< typename Pred >
        void wait( std::unique_lock< mutex > &, Pred);

        template< typename Clock, typename Duration >
        cv_status wait_until( std::unique_lock< mutex > &,
                              std::chrono::time_point< Clock, Duration > const&);

        template< typename Clock, typename Duration, typename Pred >
        bool wait_until( std::unique_lock< mutex > &,
                         std::chrono::time_point< Clock, Duration > const&,
                         Pred);

        template< typename Rep, typename Period >
        cv_status wait_for( std::unique_lock< mutex > &,
                            std::chrono::duration< Rep, Period > const&);

        template< typename Rep, typename Period, typename Pred >
        bool wait_for( std::unique_lock< mutex > &,
                       std::chrono::duration< Rep, Period > const&,
                       Pred);
    };

Constructor

    condition_variable()

Effects:

  Creates the object.

Throws:

  Nothing.

Destructor

    ~condition_variable()

Precondition:

  All fibers waiting on `*this` have been notified by a call to `notify_one` or `notify_all` (though the respective calls to `wait`, `wait_for` or `wait_until` need not have returned).

Effects:

  Destroys the object.

##### Member function `notify_one`()

    void notify_one() noexcept;

Effects:

  If any fibers are currently blocked waiting on `*this` in a call to `wait`, `wait_for` or `wait_until`, unblocks one of those fibers.

Throws:

  Nothing.

Note:

  It is arbitrary which waiting fiber is resumed.

##### Member function `notify_all`()

    void notify_all() noexcept;

Effects:

  If any fibers are currently blocked waiting on `*this` in a call to `wait`, `wait_for` or `wait_until`, unblocks all of those fibers.

Throws:

  Nothing.

Note:

  This is why a waiting fiber must also check for the desired program state using a mechanism external to the `condition_variable`, and retry the wait until that state is reached. A fiber waiting on a `condition_variable` might well wake up a number of times before the desired state is reached.

##### Templated member function `wait`()

    void wait( std::unique_lock< mutex > & lk);

    template< typename Pred >
    void wait( std::unique_lock< mutex > & lk, Pred pred);

Precondition:

  `lk` is locked by the current fiber, and either no other fiber is currently waiting on `*this`, or the execution of the `mutex()` member function on the `lk` objects supplied in the calls to `wait` in all the fibers currently waiting on `*this` would return the same value as `lk->mutex()` for this call to `wait`.

Effects:

  Atomically call `lk.unlock()` and blocks the current fiber. The fiber will unblock when notified by a call to `this->notify_one()` or `this->notify_all()`. When the fiber is unblocked (for whatever reason), the lock is reacquired by invoking `lk.lock()` before the call to `wait` returns. The lock is also reacquired by invoking `lk.lock()` if the function exits with an exception. The member function accepting `pred` is shorthand for:

      while ( ! pred() ) {
          wait( lk);
      }

Postcondition:

  `lk` is locked by the current fiber.

Throws:

  `fiber_error` if an error occurs, `fiber_interrupted` if the wait was interrupted by a call to `fiber::interrupt()` on the `fiber` object associated with the current fiber of execution.

Note:

  The Precondition is a bit dense. It merely states that all the fibers concurrently calling `wait` on `*this` must wait on `lk` objects governing the same `mutex`. Three distinct objects are involved in any `condition_variable::wait()` call: the `condition_variable` itself, the `mutex` coordinating access between fibers and a local lock object (e.g. `std::unique_lock`). In general, you can partition the lifespan of a given `condition_variable` instance into periods with one or more fibers waiting on it, separated by periods when no fibers are waiting on it. When more than one fiber is waiting on that `condition_variable`, all must pass lock objects referencing the same `mutex` instance.

##### Templated member function `wait_until`()

    template< typename Clock, typename Duration >
    cv_status wait_until( std::unique_lock< mutex > & lk,
                          std::chrono::time_point< Clock, Duration > const& abs_time);

    template< typename Clock, typename Duration, typename Pred >
    bool wait_until( std::unique_lock< mutex > & lk,
                     std::chrono::time_point< Clock, Duration > const& abs_time,
                     Pred pred);

Precondition:

  `lk` is locked by the current fiber, and either no other fiber is currently waiting on `*this`, or the execution of the `mutex()` member function on the `lk` objects supplied in the calls to `wait`, `wait_for` or `wait_until` in all the fibers currently waiting on `*this` would return the same value as `lk.mutex()` for this call to `wait_until`.

Effects:

  Atomically call `lk.unlock()` and blocks the current fiber. The fiber will unblock when notified by a call to `this->notify_one()` or `this->notify_all()`, when the system time would be equal to or later than the specified `abs_time`. When the fiber is unblocked (for whatever reason), the lock is reacquired by invoking `lk.lock()` before the call to `wait_until` returns. The lock is also reacquired by invoking `lk.lock()` if the function exits with an exception. The member function accepting `pred` is shorthand for:

      while ( ! pred() ) {
          if ( cv_status::timeout == wait_until( lk, abs_time) )
              return pred();
      }
      return true;

  That is, even if `wait_until()` times out, it can still return `true` if `pred()` returns `true` at that time.

Postcondition:

  `lk` is locked by the current fiber.

Throws:

  `fiber_error` if an error occurs, `fiber_interrupted` if the wait was interrupted by a call to `fiber::interrupt()` on the `fiber` object associated with the current fiber of execution or timeout-related exceptions.

Returns:

  The overload without `pred` returns `cv_status::no_timeout` if awakened by `notify_one()` or `notify_all()`, or `cv_status::timeout` if awakened because the system time is past `abs_time`.

Returns:

  The overload accepting `pred` returns `false` if the call is returning because the time specified by `abs_time` was reached and the predicate returns `false`, `true` otherwise.

Note:

  See Note for `condition_variable::wait()`.

##### Templated member function `wait_for`()

    template< typename Rep, typename Period >
    cv_status wait_for( std::unique_lock< mutex > & lk,
                        std::chrono::duration< Rep, Period > const& rel_time);

    template< typename Rep, typename Period, typename Pred >
    bool wait_for( std::unique_lock< mutex > & lk,
                   std::chrono::duration< Rep, Period > const& rel_time,
                   Pred pred);

Precondition:

  `lk` is locked by the current fiber, and either no other fiber is currently waiting on `*this`, or the execution of the `mutex()` member function on the `lk` objects supplied in the calls to `wait`, `wait_for` or `wait_until` in all the fibers currently waiting on `*this` would return the same value as `lk.mutex()` for this call to `wait_for`.

Effects:

  Atomically call `lk.unlock()` and blocks the current fiber. The fiber will unblock when notified by a call to `this->notify_one()` or `this->notify_all()`, when a time interval equal to or greater than the specified `rel_time` has elapsed. When the fiber is unblocked (for whatever reason), the lock is reacquired by invoking `lk.lock()` before the call to `wait` returns. The lock is also reacquired by invoking `lk.lock()` if the function exits with an exception. The `wait_for()` member function accepting `pred` is shorthand for:

      while ( ! pred() ) {
          if ( cv_status::timeout == wait_for( lk, rel_time) ) {
              return pred();
          }
      }
      return true;

  (except of course that `rel_time` is adjusted for each iteration). The point is that, even if `wait_for()` times out, it can still return `true` if `pred()` returns `true` at that time.

Postcondition:

  `lk` is locked by the current fiber.

Throws:

  `fiber_error` if an error occurs, `fiber_interrupted` if the wait was interrupted by a call to `fiber::interrupt()` on the `fiber` object associated with the current fiber of execution or timeout-related exceptions.

Returns:

  The overload without `pred` returns `cv_status::no_timeout` if awakened by `notify_one()` or `notify_all()`, or `cv_status::timeout` if awakened because at least `rel_time` has elapsed.

Returns:

  The overload accepting `pred` returns `false` if the call is returning because at least `rel_time` has elapsed and the predicate returns `false`, `true` otherwise.

Note:

  See Note for `condition_variable::wait()`.

###### Barriers

A barrier is a concept also known as a rendezvous, it is a synchronization point between multiple contexts of execution (fibers). The barrier is configured for a particular number of fibers (`n`), and as fibers reach the barrier they must wait until all `n` fibers have arrived. Once the `n`-th fiber has reached the barrier, all the waiting fibers can proceed, and the barrier is reset.

The fact that the barrier automatically resets is significant. Consider a case in which you launch some number of fibers and want to wait only until the first of them has completed. You might be tempted to use a `barrier(2)` as the synchronization mechanism, making each new fiber call its `barrier::wait()` method, then calling `wait()` in the launching fiber to wait until the first other fiber completes.

That will in fact unblock the launching fiber. The unfortunate part is that it will continue blocking the remaining fibers.

Consider the following scenario:

1. Fiber “main” launches fibers A, B, C and D, then calls `barrier::wait()`.
2. Fiber C finishes first and likewise calls `barrier::wait()`.
3. Fiber “main” is unblocked, as desired.
4. Fiber B calls `barrier::wait()`. Fiber B is blocked!
5. Fiber A calls `barrier::wait()`. Fibers A and B are unblocked.
6. Fiber D calls `barrier::wait()`. Fiber D is blocked indefinitely.

(See also when_any, simple completion.)

| Note
It is unwise to tie the lifespan of a barrier to any one of its participating fibers. Although conceptually all waiting fibers awaken “simultaneously,” because of the nature of fibers, in practice they will awaken one by one in indeterminate order.[2] The rest of the waiting fibers will still be blocked in `wait()`, which must, before returning, access data members in the barrier object.

##### Class `barrier`

    #include <boost/fiber/barrier.hpp>

    class barrier {
    public:
        explicit barrier( std::size_t);

        barrier( barrier const&) = delete;
        barrier & operator=( barrier const&) = delete;

        bool wait();
    };

Instances of `barrier` are not copyable or movable.

Constructor

    explicit barrier( std::size_t initial);

Effects:

  Construct a barrier for `initial` fibers.

Throws:

  `fiber_error`

Error Conditions:

  invalid_argument: if `initial` is zero.

##### Member function `wait`()

    bool wait();

Effects:

  Block until `initial` fibers have called `wait` on `*this`. When the `initial`-th fiber calls `wait`, all waiting fibers are unblocked, and the barrier is reset.

Returns:

  `true` for exactly one fiber from each batch of waiting fibers, `false` otherwise.

Throws:

  `fiber_error`

Notes:

  `wait()` is one of the predefined interruption-points.

###### Channels

Boost.Fiber provides a bounded and a unbounded channel suitable to synchonize fibers via message passing.

    typedef boost::fibers::unbounded_channel< int > channel_t;

    void send( channel_t & channel) {
        for ( int i = 0; i < 5; ++i) {
            channel.push( i);
        }
        channel.close();
    }

    void recv( channel_t & channel) {
        int i;
        while ( boost::fibers::channel_op_status::success == channel.pop(i) ) {
            std::cout << "received " << i << std::endl;
        }
    }

    channel_t channel;
    boost::fibers::fiber f1( std::bind( send, ref( channel) ) );
    boost::fibers::fiber f2( std::bind( recv, ref( channel) ) );

    f1.join();
    f2.join();

Enumeration `channel_op_status`

channel operations return the state of the channel.

    enum class channel_op_status {
        success,
        empty,
        full,
        closed,
        timeout
    };

`success`

Effects:

  Operation was successful.

`empty`

Effects:

  channel is empty, operation failed.

`full`

Effects:

  channel is full, operation failed.

`closed`

Effects:

  channel is closed, operation failed.

`timeout`

Effects:

  The operation did not become ready before specified timeout elapsed.

##### Template `unbounded_channel<>`

    #include <boost/fiber/unbounded_channel.hpp>

    template< typename T, typename Allocator = std::allocator< T > >
    class unbounded_channel {
    public:
        typedef T   value_type;

        explicit unbounded_channel( Allocator const& alloc = Allocator() ) noexcept;

        unbounded_channel( unbounded_channel const& other) = delete;
        unbounded_channel & operator=( unbounded_channel const& other) = delete;

        void close() noexcept;

        channel_op_status push( value_type const& va);
        channel_op_status push( value_type && va);

        channel_op_status pop( value_type & va);
        value_type value_pop();
        channel_op_status try_pop( value_type & va);
        template< typename Rep, typename Period >
        channel_op_status pop_wait_for(
            value_type & va,
            std::chrono::duration< Rep, Period > const& timeout_duration);
        template< typename Clock, typename Duration >
        channel_op_status pop_wait_until(
            value_type & va,
            std::chrono::time_point< Clock, Duration > const& timeout_time);
    };

Constructor

    explicit unbounded_channel( Allocator const& alloc = Allocator() ) noexcept;

Effects:

  Constructs an object of class `unbounded_channel`. Internal nodes are allocated using `alloc` - C++11-allocators are supported.

Throws:

  Nothing.

See also:

  `Allocator` concept, `std::allocator< T >`

##### Member function `close`()

    void close() noexcept;

Effects:

  Deactivates the channel. No values can be put after calling `this->close()`. Fibers blocked in `this->pop()`, `this->pop_wait_for()` or `this->pop_wait_until()` will return `closed`. Fibers blocked in `this->value_pop()` will receive an exception.

Throws:

  Nothing.

Note:

  `close()` is like closing a pipe. It informs waiting consumers that no more values will arrive.

##### Member function `push`()

    channel_op_status push( value_type const& va);
    channel_op_status push( value_type && va);

Effects:

  If channel is closed, returns `closed`. Otherwise enqueues the value in the channel, wakes up a fiber blocked on `this->pop()`, `this->value_pop()`, `this->pop_wait_for()` or `this->pop_wait_until()` and returns `success`.

Throws:

  Exceptions thrown by memory allocation and copying or moving `va`.

##### Member function `pop`()

    channel_op_status pop( value_type & va);

Effects:

  Dequeues a value from the channel. If the channel is empty, the fiber gets suspended until at least one new item is `push()`ed (return value `success` and `va` contains dequeued value) or the channel gets `close()`d (return value `closed`).

Throws:

  `fiber_interrupted`

##### Member function `value_pop`()

    value_type value_pop();

Effects:

  Dequeues a value from the channel. If the channel is empty, the fiber gets suspended until at least one new item is `push()`ed or the channel gets `close()`d (which throws an exception).

Throws:

  `fiber_error` if `*this` is closed or `fiber_interrupted`

Error conditions:

  `std::errc::operation_not_permitted`

##### Member function `try_pop`()

    channel_op_status try_pop( value_type & va);

Effects:

  If channel is empty, returns `empty`. If channel is closed, returns `closed`. Otherwise it returns `success` and `va` contains the dequeued value.

Throws:

  Exceptions thrown by copy- or move-operations.

##### Member function `pop_wait_for`()

    template< typename Rep, typename Period >
    channel_op_status pop_wait_for(
        value_type & va,
        std::chrono::duration< Rep, Period > const& timeout_duration)

Effects:

  Accepts `std::chrono::duration` and internally computes a timeout time as (system time + `timeout_duration`). If channel is not empty, immediately dequeues a value from the channel. Otherwise the fiber gets suspended until at least one new item is `push()`ed (return value `success` and `va` contains dequeued value), or the channel gets `close()`d (return value `closed`), or the system time reaches the computed timeout time (return value `timeout`).

Throws:

  `fiber_interrupted` or timeout-related exceptions.

##### Member function `pop_wait_until`()

    template< typename Clock, typename Duration >
    channel_op_status pop_wait_until(
        value_type & va,
        std::chrono::time_point< Clock, Duration > const& timeout_time)

Effects:

  Accepts a `std::chrono::time_point< Clock, Duration >`. If channel is not empty, immediately dequeues a value from the channel. Otherwise the fiber gets suspended until at least one new item is `push()`ed (return value `success` and `va` contains dequeued value), or the channel gets `close()`d (return value `closed`), or the system time reaches the passed `time_point` (return value `timeout`).

Throws:

  `fiber_interrupted` or timeout-related exceptions.

##### Template `bounded_channel<>`

    #include <boost/fiber/bounded_channel.hpp>

    template< typename T, typename Allocator = std::allocator< T > >
    class bounded_channel {
    public:
        typedef T   value_type;

        bounded_channel( std::size_t wm, Allocator const& alloc = Allocator() );
        bounded_channel( std::size_t hwm, std::size_t lwm, Allocator const& alloc = Allocator() );

        bounded_channel( bounded_channel const& other) = delete;
        bounded_channel & operator=( bounded_channel const& other) = delete;

        std::size_t upper_bound() const noexcept;
        std::size_t lower_bound() const noexcept;

        void close() noexcept;

        channel_op_status push( value_type const& va);
        channel_op_status push( value_type && va);
        template< typename Rep, typename Period >
        channel_op_status push_wait_for(
            value_type const& va,
            std::chrono::duration< Rep, Period > const& timeout_duration);
        channel_op_status push_wait_for( value_type && va,
            std::chrono::duration< Rep, Period > const& timeout_duration);
        template< typename Clock, typename Duration >
        channel_op_status push_wait_until(
            value_type const& va,
            std::chrono::time_point< Clock, Duration > const& timeout_time);
        template< typename Clock, typename Duration >
        channel_op_status push_wait_until(
            value_type && va,
            std::chrono::time_point< Clock, Duration > const& timeout_time);
        channel_op_status try_push( value_type const& va);
        channel_op_status try_push( value_type && va);

        channel_op_status pop( value_type & va);
        value_type value_pop();
        template< typename Rep, typename Period >
        channel_op_status pop_wait_for(
            value_type & va,
            std::chrono::duration< Rep, Period > const& timeout_duration);
        template< typename Clock, typename Duration >
        channel_op_status pop_wait_until(
            value_type & va,
            std::chrono::time_point< Clock, Duration > const& timeout_time);
        channel_op_status try_pop( value_type & va);
    };

Constructor

    bounded_channel( std::size_t wm, Allocator const& alloc = Allocator() );
    bounded_channel( std::size_t hwm, std::size_t lwm, Allocator const& alloc = Allocator() );

Preconditions:

  `hwm > lwm`

Effects:

  Constructs an object of class `bounded_channel`. The constructor with two arguments constructs an object of class `bounded_channel` with a high-watermark of `hwm` and a low-watermark of `lwm` items. The constructor with one `std::size_t` argument is effectively the same as `bounded_channel(wm, (wm-1), alloc)`. Internal nodes are allocated using `alloc` - C++11-allocators are supported.

Throws:

  `fiber_error`

Error Conditions:

  invalid_argument: if `lwm >= hwm`.

Notes:

  Once the number of values in the channel reaches `hwm`, any call to `push()`, `push_wait_for()` or `push_wait_until()` will block until the number of values in the channel is at most `lwm`. That is, if `lwm < (hwm-1)`, the channel can be in a state in which `push()`, `push_wait_for()` or `push_wait_until()` calls will block (channel is full) even though the number of values in the channel is less than `hwm`.

See also:

  `Allocator` concept, `std::allocator< T >`

##### Member function `upper_bound`()

    std::size_t upper_bound() const noexcept;

Returns:

  the high-watermark with which `*this` was constructed.

Throws:

  Nothing.

##### Member function `lower_bound`()

    std::size_t lower_bound() const noexcept;

Returns:

  the low-watermark with which `*this` was constructed.

Throws:

  Nothing.

##### Member function `close`()

    void close() noexcept;

Effects:

  Deactivates the channel. No values can be put after calling `this->close()`. Fibers blocked in `this->pop()`, `this->pop_wait_for()` or `this->pop_wait_until()` will return `closed`. Fibers blocked in `this->value_pop()` will receive an exception.

Throws:

  Nothing.

Note:

  `close()` is like closing a pipe. It informs waiting consumers that no more values will arrive.

##### Member function `push`()

    channel_op_status push( value_type const& va);
    channel_op_status push( value_type && va);

Effects:

  If channel is closed, returns `closed`. If channel is not full, enqueues the value in the channel, wakes up a fiber blocked on `this->pop()`, `this->value_pop()`, `this->pop_wait_for()` or `this->pop_wait_until()` and returns `success`. Otherwise the calling fiber is suspended until the number of values in the channel drops to `lwm` (return value `success`)or the channel is `close()`d (return value `closed`).

Throws:

  `fiber_interrupted` or exceptions thrown by memory allocation and copying or moving `va`.

##### Member function `push_wait_for`()

    template< typename Rep, typename Period >
    channel_op_status push_wait_for(
        value_type const& va,
        std::chrono::duration< Rep, Period > const& timeout_duration);

    template< typename Rep, typename Period >
    channel_op_status push_wait_for(
        value_type && va,
        std::chrono::duration< Rep, Period > const& timeout_duration);

Effects:

  Accepts `std::chrono::duration` and internally computes a time_point as (system time + `timeout_duration`). If channel is closed, returns `closed`. If channel is not full, enqueues the value in the channel, wakes up a fiber blocked on `this->pop()`, `this->value_pop()`, `this->pop_wait_for()` or `this->pop_wait_until()` and returns `success`. Otherwise the calling fiber is suspended until the number of values in the channel drops to `lwm` (return value `success`), the channel is `close()`d (return value `closed`), or the system time reaches the computed time_point (return value `timeout`).

Throws:

  `fiber_interrupted`, exceptions thrown by memory allocation and copying or moving `va` or timeout-related exceptions.

##### Member function `push_wait_until`()

    template< typename Clock, typename Duration >
    channel_op_status push_wait_until(
        value_type const& va,
        std::chrono::time_point< Clock, Duration > const& timeout_time);

    template< typename Clock, typename Duration >
    channel_op_status push_wait_until(
        value_type && va,
        std::chrono::time_point< Clock, Duration > const& timeout_time);

Effects:

  Accepts an absolute `timeout_time` in any supported time_point type. If channel is closed, returns `closed`. If channel is not full, enqueues the value in the channel, wakes up a fiber blocked on `this->pop()`, `this->value_pop()`, `this->pop_wait_for()` or `this->pop_wait_until()` and returns `success`. Otherwise the calling fiber is suspended until the number of values in the channel drops to `lwm` (return value `success`), the channel is `close()`d (return value `closed`), or the system time reaches the passed time_point (return value `timeout`).

Throws:

  `fiber_interrupted` or exceptions thrown by memory allocation and copying or moving `va` or timeout-related exceptions.

##### Member function `try_push`()

    channel_op_status try_push( value_type const& va);
    channel_op_status try_push( value_type && va);

Effects:

  If channel is full, returns `full`. If channel is closed, returns `closed`. Otherwise enqueues the value in the channel, wakes up a fiber blocked on `this->pop()`, `this->value_pop()`, `this->pop_wait_for()` or `this->pop_wait_until()` and returns `success`.

Throws:

  Exceptions thrown by memory allocation and copying or moving `va`.

##### Member function `pop`()

    channel_op_status pop( value_type & va);

Effects:

  Dequeues a value from the channel. If the channel is empty, the fiber gets suspended until at least one new item is `push()`ed (return value `success` and `va` contains dequeued value) or the channel gets `close()`d (return value `closed`). Once the number of items remaining in the channel drops to `lwm`, any fibers blocked on `push()`, `push_wait_for()` or `push_wait_until()` may resume.

Throws:

  `fiber_interrupted`

##### Member function `value_pop`()

    value_type value_pop();

Effects:

  Dequeues a value from the channel. If the channel is empty, the fiber gets suspended until at least one new item is `push()`ed or the channel gets `close()`d (which throws an exception). Once the number of items remaining in the channel drops to `lwm`, any fibers blocked on `push()`, `push_wait_for()` or `push_wait_until()` may resume.

Throws:

  `fiber_error` if `*this` is closed or `fiber_interrupted`

Error conditions:

  `std::errc::operation_not_permitted`

##### Member function `try_pop`()

    channel_op_status try_pop( value_type & va);

Effects:

  If channel is empty, returns `empty`. If channel is closed, returns `closed`. Otherwise it returns `success` and `va` contains the dequeued value. Once the number of items remaining in the channel drops to `lwm`, any fibers blocked on `push()`, `push_wait_for()` or `push_wait_until()` may resume.

Throws:

  Exceptions thrown by copy- or move-operations.

##### Member function `pop_wait_for`()

    template< typename Rep, typename Period >
    channel_op_status pop_wait_for(
        value_type & va,
        std::chrono::duration< Rep, Period > const& timeout_duration)

Effects:

  Accepts `std::chrono::duration` and internally computes a timeout time as (system time + `timeout_duration`). If channel is not empty, immediately dequeues a value from the channel. Otherwise the fiber gets suspended until at least one new item is `push()`ed (return value `success` and `va` contains dequeued value), or the channel gets `close()`d (return value `closed`), or the system time reaches the computed timeout time (return value `timeout`). Once the number of items remaining in the channel drops to `lwm`, any fibers blocked on `push()`, `push_wait_for()` or `push_wait_until()` may resume.

Throws:

  `fiber_interrupted` or timeout-related exceptions.

##### Member function `pop_wait_until`()

    template< typename Clock, typename Duration >
    channel_op_status pop_wait_until(
        value_type & va,
        std::chrono::time_point< Clock, Duration > const& timeout_time)

Effects:

  Accepts a `std::chrono::time_point< Clock, Duration >`. If channel is not empty, immediately dequeues a value from the channel. Otherwise the fiber gets suspended until at least one new item is `push()`ed (return value `success` and `va` contains dequeued value), or the channel gets `close()`d (return value `closed`), or the system time reaches the passed `time_point` (return value `timeout`). Once the number of items remaining in the channel drops to `lwm`, any fibers blocked on `push()`, `push_wait_for()` or `push_wait_until()` may resume.

Throws:

  `fiber_interrupted` or timeout-related exceptions.

###### Futures

Overview

The futures library provides a means of handling asynchronous future values, whether those values are generated by another fiber, or on a single fiber in response to external stimuli, or on-demand.

This is done through the provision of four class templates: `future<>` and `shared_future<>` which are used to retrieve the asynchronous results, and `promise<>` and `packaged_task<>` which are used to generate the asynchronous results.

An instance of `future<>` holds the one and only reference to a result. Ownership can be transferred between instances using the move constructor or move-assignment operator, but at most one instance holds a reference to a given asynchronous result. When the result is ready, it is returned from `future::get()` by rvalue-reference to allow the result to be moved or copied as appropriate for the type.

On the other hand, many instances of `shared_future<>` may reference the same result. Instances can be freely copied and assigned, and `shared_future::get()` returns a `const` reference so that multiple calls to `shared_future::get()` are safe. You can move an instance of `future<>` into an instance of `shared_future<>`, thus transferring ownership of the associated asynchronous result, but not vice-versa.

`fibers::async()` is a simple way of running asynchronous tasks. A call to `async()` spawns a fiber and returns a `future<>` that will deliver the result of the fiber function.

Creating asynchronous values

You can set the value in a future with either a `promise<>` or a `packaged_task<>`. A `packaged_task<>` is a callable object with `void` return that wraps a function or callable object returning the specified type. When the `packaged_task<>` is invoked, it invokes the contained function in turn, and populates a future with the contained function's return value. This is an answer to the perennial question: “How do I return a value from a fiber?” Package the function you wish to run as a `packaged_task<>` and pass the packaged task to the fiber constructor. The future retrieved from the packaged task can then be used to obtain the return value. If the function throws an exception, that is stored in the future in place of the return value.

    int calculate_the_answer_to_life_the_universe_and_everything() {
        return 42;
    }

    boost::fibers::packaged_task<int()> pt(calculate_the_answer_to_life_the_universe_and_everything);
    boost::fibers::future<int> fi=pt.get_future();
    boost::fibers::fiber(std::move(pt)).detach(); // launch task on a fiber

    fi.wait(); // wait for it to finish

    assert(fi.is_ready());
    assert(fi.has_value());
    assert(!fi.has_exception());
    assert(fi.get()==42);

A `promise<>` is a bit more low level: it just provides explicit functions to store a value or an exception in the associated future. A promise can therefore be used where the value might come from more than one possible source.

    boost::fibers::promise<int> pi;
    boost::fibers::future<int> fi;
    fi=pi.get_future();

    pi.set_value(42);

    assert(fi.is_ready());
    assert(fi.has_value());
    assert(!fi.has_exception());
    assert(fi.get()==42);

###### Future

A future provides a mechanism to access the result of an asynchronous operation.

shared state

Behind a `promise<>` and its `future<>` lies an unspecified object called their shared state. The shared state is what will actually hold the async result (or the exception).

The shared state is instantiated along with the `promise<>`.

Aside from its originating `promise<>`, a `future<>` holds a unique reference to a particular shared state. However, multiple `shared_future<>` instances can reference the same underlying shared state.

As `packaged_task<>` and `fibers::async()` are implemented using `promise<>`, discussions of shared state apply to them as well.

Enumeration `future_status`

Timed wait-operations ( `future::wait_for()` and `future::wait_until()`) return the state of the future.

    enum class future_status {
        ready,
        timeout,
        deferred  // not supported yet
    };

`ready`

Effects:

  The shared state is ready.

`timeout`

Effects:

  The shared state did not become ready before timeout has passed.

| Note
Deferred futures are not supported.

##### Template `future<>`

A `future<>` contains a shared state which is not shared with any other future.

    template< typename R >
    class future {
    public:
        future() noexcept;

        future( future const& other) = delete;

        future & operator=( future const& other) = delete;

        future( future && other) noexcept;

        future & operator=( future && other) noexcept;

        ~future();

        bool valid() const noexcept;

        shared_future< R > share();

        R get();    // member only of generic future template
        R & get();  // member only of future< R & > template specialization
        void get(); // member only of future< void > template specialization

        std::exception_ptr get_exception_ptr();

        void wait() const;

        template< class Rep, class Period >
        future_status wait_for(
            std::chrono::duration< Rep, Period > const& timeout_duration) const;

        template< typename Clock, typename Duration >
        future_status wait_until(
            std::chrono::time_point< Clock, Duration > const& timeout_time) const;
    };

Default constructor

    future() noexcept;

Effects:

  Creates a future with no shared state. After construction `false == valid()`.

Throws:

  Nothing.

Move constructor

    future( future && other) noexcept;

Effects:

  Constructs a future with the shared state of other. After construction `false == other.valid()`.

Throws:

  Nothing.

Destructor

    ~future();

Effects:

  Destroys the future; ownership is abandoned.

Note:

  `~future()` does not block the calling fiber.

Consider a sequence such as:

1. instantiate `promise<>`
2. obtain its `future<>` via `promise::get_future()`
3. launch `fiber`, capturing `promise<>`
4. destroy `future<>`
5. call `promise::set_value()`

The final `set_value()` call succeeds, but the value is silently discarded: no additional `future<>` can be obtained from that `promise<>`.

##### Member function `operator=`()

    future & operator=( future && other) noexcept;

Effects:

  Moves the shared state of other to `this`. After the assignment, `false == other.valid()`.

Throws:

  Nothing.

##### Member function `valid`()

    bool valid() const noexcept;

Effects:

  Returns `true` if future contains a shared state.

Throws:

  Nothing.

##### Member function `share`()

    shared_future< R > share();

Effects:

  Move the state to a `shared_future<>`.

Returns:

  a `shared_future<>` containing the shared state formerly belonging to `*this`.

Postcondition:

  `false == valid()`

Throws:

  `future_error` with error condition `future_errc::no_state`.

##### Member function `get`()

    R get();    // member only of generic future template
    R & get();  // member only of future< R & > template specialization
    void get(); // member only of future< void > template specialization

Precondition:

  `true == valid()`

Returns:

  Waits until `promise::set_value()` or `promise::set_exception()` is called. If `promise::set_value()` is called, returns the value. If `promise::set_exception()` is called, throws the indicated exception.

Postcondition:

  `false == valid()`

Throws:

  `future_error` with error condition `future_errc::no_state`, `fiber_interrupted`, `future_errc::broken_promise`. Any exception passed to `promise::set_exception()`.

##### Member function `get_exception_ptr`()

    std::exception_ptr get_exception_ptr();

Precondition:

  `true == valid()`

Returns:

  Waits until `promise::set_value()` or `promise::set_exception()` is called. If `set_value()` is called, returns a default-constructed `std::exception_ptr`. If `set_exception()` is called, returns the passed `std::exception_ptr`.

Throws:

  `future_error` with error condition `future_errc::no_state` or `fiber_interrupted`.

Note:

  `get_exception_ptr()` does not invalidate the `future`. After calling `get_exception_ptr()`, you may still call `future::get()`.

##### Member function `wait`()

    void wait();

Effects:

  Waits until `promise::set_value()` or `promise::set_exception()` is called.

Throws:

  `future_error` with error condition `future_errc::no_state` or `fiber_interrupted`.

##### Templated member function `wait_for`()

    template< class Rep, class Period >
    future_status wait_for( std::chrono::duration< Rep, Period > const& timeout_duration) const;

Effects:

  Waits until `promise::set_value()` or `promise::set_exception()` is called, or `timeout_duration` has passed.

Result:

  A `future_status` is returned indicating the reason for returning.

Throws:

  `future_error` with error condition `future_errc::no_state` or `fiber_interrupted` or timeout-related exceptions.

##### Templated member function `wait_until`()

    template< typename Clock, typename Duration >
    future_status wait_until( std::chrono::time_point< Clock, Duration > const& timeout_time) const;

Effects:

  Waits until `promise::set_value()` or `promise::set_exception()` is called, or `timeout_time` has passed.

Result:

  A `future_status` is returned indicating the reason for returning.

Throws:

  `future_error` with error condition `future_errc::no_state` or `fiber_interrupted` or timeout-related exceptions.

##### Template `shared_future<>`

A `shared_future<>` contains a shared state which might be shared with other `shared_future<>` instances.

    template< typename R >
    class shared_future {
    public:
        shared_future() noexcept;

        ~shared_future();

        shared_future( shared_future const& other);

        shared_future( future< R > && other) noexcept;

        shared_future( shared_future && other) noexcept;

        shared_future & operator=( shared_future && other) noexcept;

        shared_future & operator=( future< R > && other) noexcept;

        shared_future & operator=( shared_future const& other) noexcept;

        bool valid() const noexcept;

        R const& get(); // member only of generic shared_future template
        R & get();      // member only of shared_future< R & > template specialization
        void get();     // member only of shared_future< void > template specialization

        std::exception_ptr get_exception_ptr();

        void wait() const;

        template< class Rep, class Period >
        future_status wait_for(
            std::chrono::duration< Rep, Period > const& timeout_duration) const;

        template< typename Clock, typename Duration >
        future_status wait_until(
            std::chrono::time_point< Clock, Duration > const& timeout_time) const;
    };

Default constructor

    shared_future();

Effects:

  Creates a shared_future with no shared state. After construction `false == valid()`.

Throws:

  Nothing.

Move constructor

    shared_future( future< R > && other) noexcept;
    shared_future( shared_future && other) noexcept;

Effects:

  Constructs a shared_future with the shared state of other. After construction `false == other.valid()`.

Throws:

  Nothing.

Copy constructor

    shared_future( shared_future const& other) noexcept;

Effects:

  Constructs a shared_future with the shared state of other. After construction `other.valid()` is unchanged.

Throws:

  Nothing.

Destructor

    ~shared_future();

Effects:

  Destroys the shared_future; ownership is abandoned if not shared.

Note:

  `~shared_future()` does not block the calling fiber.

##### Member function `operator=`()

    shared_future & operator=( future< R > && other) noexcept;
    shared_future & operator=( shared_future && other) noexcept;
    shared_future & operator=( shared_future const& other) noexcept;

Effects:

  Moves or copies the shared state of other to `this`. After the assignment, the state of `other.valid()` depends on which overload was invoked: unchanged for the overload accepting `shared_future const&`, otherwise `false`.

Throws:

  Nothing.

##### Member function `valid`()

    bool valid() const noexcept;

Effects:

  Returns `true` if shared_future contains a shared state.

Throws:

  Nothing.

##### Member function `get`()

    R const& get(); // member only of generic shared_future template
    R & get();      // member only of shared_future< R & > template specialization
    void get();     // member only of shared_future< void > template specialization

Precondition:

  `true == valid()`

Returns:

  Waits until `promise::set_value()` or `promise::set_exception()` is called. If `promise::set_value()` is called, returns the value. If `promise::set_exception()` is called, throws the indicated exception.

Postcondition:

  `false == valid()`

Throws:

  `future_error` with error condition `future_errc::no_state`, `fiber_interrupted`, `future_errc::broken_promise`. Any exception passed to `promise::set_exception()`.

##### Member function `get_exception_ptr`()

    std::exception_ptr get_exception_ptr();

Precondition:

  `true == valid()`

Returns:

  Waits until `promise::set_value()` or `promise::set_exception()` is called. If `set_value()` is called, returns a default-constructed `std::exception_ptr`. If `set_exception()` is called, returns the passed `std::exception_ptr`.

Throws:

  `future_error` with error condition `future_errc::no_state` or `fiber_interrupted`.

Note:

  `get_exception_ptr()` does not invalidate the `shared_future`. After calling `get_exception_ptr()`, you may still call `shared_future::get()`.

##### Member function `wait`()

    void wait();

Effects:

  Waits until `promise::set_value()` or `promise::set_exception()` is called.

Throws:

  `future_error` with error condition `future_errc::no_state` or `fiber_interrupted`.

##### Templated member function `wait_for`()

    template< class Rep, class Period >
    future_status wait_for( std::chrono::duration< Rep, Period > const& timeout_duration) const;

Effects:

  Waits until `promise::set_value()` or `promise::set_exception()` is called, or `timeout_duration` has passed.

Result:

  A `future_status` is returned indicating the reason for returning.

Throws:

  `future_error` with error condition `future_errc::no_state` or `fiber_interrupted` or timeout-related exceptions.

##### Templated member function `wait_until`()

    template< typename Clock, typename Duration >
    future_status wait_until( std::chrono::time_point< Clock, Duration > const& timeout_time) const;

Effects:

  Waits until `promise::set_value()` or `promise::set_exception()` is called, or `timeout_time` has passed.

Result:

  A `future_status` is returned indicating the reason for returning.

Throws:

  `future_error` with error condition `future_errc::no_state` or `fiber_interrupted` or timeout-related exceptions.

##### Non-member function `fibers::async()`

    #include <boost/fiber/future/async.hpp>

    template< class Function, class ... Args >
    future<
        std::result_of_t<
            std::decay_t< Function >( std::decay_t< Args > ... )
        >
    >
    async( Function && fn, Args && ... args);

    template< typename StackAllocator, class Function, class ... Args >
    future<
        std::result_of_t<
            std::decay_t< Function >( std::decay_t< Args > ... )
        >
    >
    async( std::allocator_arg_t, StackAllocator salloc, Function && fn, Args && ... args);

Effects:

  Executes `fn` in a `fiber` and returns an associated `future<>`.

Result:

      future<
          std::result_of_t<
              std::decay_t< Function >( std::decay_t< Args > ... )
          >
      >

  representing the shared state associated with the asynchronous execution of `fn`.

Throws:

  `fiber_error` or `future_error` if an error occurs.

Notes:

  The overload accepting `std::allocator_arg_t` uses the passed `StackAllocator` when constructing the launched `fiber`.

| Note
Deferred futures are not supported.

###### Template `promise<>`

A `promise<>` provides a mechanism to store a value (or exception) that can later be retrieved from the corresponding `future<>` object. `promise<>` and `future<>` communicate via their underlying shared state.

    template< typename R >
    class promise {
    public:
        promise();

        template< typename Allocator >
        promise( std::allocator_arg_t, Allocator);

        promise( promise &&) noexcept;

        promise & operator=( promise &&) noexcept;

        promise( promise const&) = delete;

        promise & operator=( promise const&) = delete;

        ~promise();

        void swap( promise &) noexcept;

        future< R > get_future();

        void set_value( R const&);  // member only of generic promise template
        void set_value( R &&);      // member only of generic promise template
        void set_value( R &);       // member only of promise< R & > template
        void set_value();           // member only of promise< void > template

        void set_exception( std::exception_ptr p);
    };

    template< typename R >
    void swap( promise< R > &, promise< R > &) noexcept;

Default constructor

    promise();

Effects:

  Creates a promise with an empty shared state.

Throws:

  Exceptions caused by memory allocation.

Constructor

    template< typename Allocator >
    promise( std::allocator_arg_t, Allocator alloc);

Effects:

  Creates a promise with an empty shared state by using `alloc`.

Throws:

  Exceptions caused by memory allocation.

See also:

  `std::allocator_arg_t`

Move constructor

    promise( promise && other) noexcept;

Effects:

  Creates a promise by moving the shared state from `other`.

Postcondition:

  `other` contains no valid shared state.

Throws:

  Nothing.

Destructor

    ~promise();

Effects:

  Destroys `*this` and abandons the shared state if shared state is ready; otherwise stores `future_error` with error condition `future_errc::broken_promise` as if by `promise::set_exception()`: the shared state is set ready.

##### Member function `operator=`()

    promise & operator=( promise && other) noexcept;

Effects:

  Transfers the ownership of shared state to `*this`.

Postcondition:

  `other` contains no valid shared state.

Throws:

  Nothing.

##### Member function `swap`()

    void swap( promise & other) noexcept;

Effects:

  Swaps the shared state between other and `*this`.

Throws:

  Nothing.

##### Member function `get_future`()

    future< R > get_future();

Returns:

  A `future<>` with the same shared state.

Throws:

  `future_error` with `future_errc::future_already_retrieved` or `future_errc::no_state`.

##### Member function `set_value`()

    void set_value( R const& value);  // member only of generic promise template
    void set_value( R && value);      // member only of generic promise template
    void set_value( R & value);       // member only of promise< R & > template
    void set_value();                 // member only of promise< void > template

Effects:

  Store the result in the shared state and marks the state as ready.

Throws:

  `future_error` with `future_errc::future_already_satisfied` or `future_errc::no_state`.

##### Member function `set_exception`()

    void set_exception( std::exception_ptr);

Effects:

  Store an exception pointer in the shared state and marks the state as ready.

Throws:

  `future_error` with `future_errc::future_already_satisfied` or `future_errc::no_state`.

##### Non-member function `swap()`

    template< typename R >
    void swap( promise< R > & l, promise< R > & r) noexcept;

Effects:

  Same as `l.swap( r)`.

###### Template `packaged_task<>`

A `packaged_task<>` wraps a callable target that returns a value so that the return value can be computed asynchronously.

Conventional usage of `packaged_task<>` is like this:

1. Instantiate `packaged_task<>` with template arguments matching the signature of the callable. Pass the callable to the constructor.
2. Call `packaged_task::get_future()` and capture the returned `future<>` instance.
3. Launch a `fiber` to run the new `packaged_task<>`, passing any arguments required by the original callable.
4. Call `fiber::detach()` on the newly-launched `fiber`.
5. At some later point, retrieve the result from the `future<>`.

This is, in fact, pretty much what `fibers::async()` encapsulates.

    template< class R, typename ... Args >
    class packaged_task< R( Args ... ) > {
    public:
        packaged_task() noexcept;

        template< typename Fn >
        explicit packaged_task( Fn &&);

        template< typename Fn, typename Allocator >
        packaged_task( std::allocator_arg_t, Allocator const&, Fn &&);

        packaged_task( packaged_task &&) noexcept;

        packaged_task & operator=( packaged_task &&) noexcept;

        packaged_task( packaged_task const&) = delete;

        packaged_task & operator=( packaged_task const&) = delete;

        ~packaged_task();

        void swap( packaged_task &) noexcept;

        bool valid() const noexcept;

        future< R > get_future();

        void operator()( Args ...);

        void reset();
    };

    template< typename Signature >
    void swap( packaged_task< Signature > &, packaged_task< Signature > &) noexcept;

Default constructor `packaged_task()`

    packaged_task() noexcept;

Effects:

  Constructs an object of class `packaged_task` with no shared state.

Throws:

  Nothing.

Templated constructor `packaged_task()`

    template< typename Fn >
    explicit packaged_task( Fn && fn);

    template< typename Fn, typename Allocator >
    packaged_task( std::allocator_arg_t, Allocator const& alloc, Fn && fn);

Effects:

  Constructs an object of class `packaged_task` with a shared state and copies or moves the callable target `fn` to internal storage.

Throws:

  Exceptions caused by memory allocation.

Note:

  The signature of `Fn` should have a return type convertible to `R`.

See also:

  `std::allocator_arg_t`

Move constructor

    packaged_task( packaged_task && other) noexcept;

Effects:

  Creates a packaged_task by moving the shared state from `other`.

Postcondition:

  `other` contains no valid shared state.

Throws:

  Nothing.

Destructor

    ~packaged_task();

Effects:

  Destroys `*this` and abandons the shared state if shared state is ready; otherwise stores `future_error` with error condition `future_errc::broken_promise` as if by `promise::set_exception()`: the shared state is set ready.

##### Member function `operator=`()

    packaged_task & operator=( packaged_task && other) noexcept;

Effects:

  Transfers the ownership of shared state to `*this`.

Postcondition:

  `other` contains no valid shared state.

Throws:

  Nothing.

##### Member function `swap`()

    void swap( packaged_task & other) noexcept;

Effects:

  Swaps the shared state between other and `*this`.

Throws:

  Nothing.

##### Member function `valid`()

    bool valid() const noexcept;

Effects:

  Returns `true` if `*this` contains a shared state.

Throws:

  Nothing.

##### Member function `get_future`()

    future< R > get_future();

Returns:

  A `future<>` with the same shared state.

Throws:

  `future_error` with `future_errc::future_already_retrieved` or `future_errc::no_state`.

##### Member function `operator()`()

    void operator()( Args && ... args);

Effects:

  Invokes the stored callable target. Any exception thrown by the callable target `fn` is stored in the shared state as if by `promise::set_exception()`. Otherwise, the value returned by `fn` is stored in the shared state as if by `promise::set_value()`.

Throws:

  `future_error` with `future_errc::no_state`.

##### Member function `reset`()

    void reset();

Effects:

  Resets the shared state and abandons the result of previous executions. A new shared state is constructed.

Throws:

  `future_error` with `future_errc::no_state`.

##### Non-member function `swap()`

    template< typename Signature >
    void swap( packaged_task< Signature > & l, packaged_task< Signature > & r) noexcept;

Effects:

  Same as `l.swap( r)`.

##### Fiber local storage

###### Synopsis

Fiber local storage allows a separate instance of a given data item for each fiber.

###### Cleanup at fiber exit

When a fiber exits, the objects associated with each `fiber_specific_ptr` instance are destroyed. By default, the object pointed to by a pointer `p` is destroyed by invoking `delete p`, but this can be overridden for a specific instance of `fiber_specific_ptr` by providing a cleanup routine `func` to the constructor. In this case, the object is destroyed by invoking `func(p)`. The cleanup functions are called in an unspecified order.

##### Class `fiber_specific_ptr`

    #include <boost/fiber/fss.hpp>

    template< typename T >
    class fiber_specific_ptr {
    public:
        typedef T   element_type;

        fiber_specific_ptr();

        explicit fiber_specific_ptr( void(*fn)(T*) );

        ~fiber_specific_ptr();

        fiber_specific_ptr( fiber_specific_ptr const&) = delete;
        fiber_specific_ptr & operator=( fiber_specific_ptr const&) = delete;

        T * get() const noexcept;

        T * operator->() const noexcept;

        T & operator*() const noexcept;

        T * release();

        void reset( T *);
    };

###### Constructor

    fiber_specific_ptr();
    explicit fiber_specific_ptr( void(*fn)(T*) );

Requires:

  `delete this->get()` is well-formed; `fn(this->get())` does not throw

Effects:

  Construct a `fiber_specific_ptr` object for storing a pointer to an object of type `T` specific to each fiber. When `reset()` is called, or the fiber exits, `fiber_specific_ptr` calls `fn(this->get())`. If the no-arguments constructor is used, the default `delete`-based cleanup function will be used to destroy the fiber-local objects.

Throws:

  `fiber_error` if an error occurs.

###### Destructor

    ~fiber_specific_ptr();

Requires:

  All the fiber specific instances associated to this `fiber_specific_ptr` (except maybe the one associated to this fiber) must be nullptr.

Effects:

  Calls `this->reset()` to clean up the associated value for the current fiber, and destroys `*this`.

Remarks:

  The requirement is an implementation restriction. If the destructor promised to delete instances for all fibers, the implementation would be forced to maintain a list of all the fibers having an associated specific ptr, which is against the goal of fiber specific data. In general, a `fiber_specific_ptr` should outlive the fibers that use it.

| Note
Care needs to be taken to ensure that any fibers still running after an instance of `fiber_specific_ptr` has been destroyed do not call any member functions on that instance.

##### Member function `get`()

    T * get() const noexcept;

Returns:

  The pointer associated with the current fiber.

Throws:

  Nothing.

| Note
The initial value associated with an instance of `fiber_specific_ptr` is `nullptr` for each fiber.

##### Member function `operator->`()

    T * operator->() const noexcept;

Requires:

  `this->get()` is not `nullptr`.

Returns:

  `this->get()`

Throws:

  Nothing.

##### Member function `operator*`()

    T & operator*() const noexcept;

Requires:

  `this->get()` is not `nullptr`.

Returns:

  `*(this->get())`

Throws:

  Nothing.

##### Member function `release`()

    T * release();

Effects:

  Return `this->get()` and store `nullptr` as the pointer associated with the current fiber without invoking the cleanup function.

Postcondition:

  `this->get()==nullptr`

Throws:

  Nothing.

##### Member function `reset`()

    void reset( T * new_value);

Effects:

  If `this->get()!=new_value` and `this->get()` is not `nullptr`, invoke `delete this->get()` or `fn(this->get())` as appropriate. Store `new_value` as the pointer associated with the current fiber.

Postcondition:

  `this->get()==new_value`

Throws:

  Exception raised during cleanup of previous value.

##### Migrating fibers between threads

###### Overview

Each fiber owns a stack and manages its execution state, including all registers and CPU flags, the instruction pointer and the stack pointer. That means, in general, a fiber is not bound to a specific thread.[3] ,[4]

Migrating a fiber from a logical CPU with heavy workload to another logical CPU with a lighter workload might speed up the overall execution. Note that in the case of NUMA-architectures, it is not always advisable to migrate data between threads. Suppose fiber f is running on logical CPU cpu0 which belongs to NUMA node node0. The data of f are allocated on the physical memory located at node0. Migrating the fiber from cpu0 to another logical CPU cpuX which is part of a different NUMA node nodeX might reduce the performance of the application due to increased latency of memory access.

Only fibers that are contained in `sched_algorithm`'s ready queue can migrate between threads. You cannot migrate a running fiber, nor one that is blocked.

InBoost.Fiber a fiber is migrated by invoking `context::migrate()` on the `context` instance for a fiber already associated with the destination thread, passing the `context` for the fiber to be migrated.

###### Example of work sharing

In the example work_sharing.cpp multiple worker fibers are created on the main thread. Each fiber gets a character as parameter at construction. This character is printed out ten times. Between each iteration the fiber calls `this_fiber::yield()`. That puts the fiber in the ready queue of the fiber-scheduler shared_ready_queue, running in the current thread. The next fiber ready to be executed is dequeued from the shared ready queue and resumed by shared_ready_queue running on any participating thread.

All instances of shared_ready_queue share one global concurrent queue, used as ready queue. This mechanism shares all worker fibers between all instances of shared_ready_queue, thus between all participating threads.

###### Setup of threads and fibers

In `main()` the fiber-scheduler is installed and the worker fibers and the threads are launched.

    boost::fibers::use_scheduling_algorithm< shared_ready_queue >();

    for ( char c : std::string("abcdefghijklmnopqrstuvwxyz")) {
        boost::fibers::fiber([c](){ whatevah( c); }).detach();
        ++fiber_count;
    }
    barrier b( 4);
    std::thread threads[] = {
        std::thread( thread, & b),
        std::thread( thread, & b),
        std::thread( thread, & b)
    };
    b.wait();
    {
        lock_t lk( mtx_count);
        cnd_count.wait( lk, [](){ return 0 == fiber_count; } );
    }
    BOOST_ASSERT( 0 == fiber_count);
    for ( std::thread & t : threads) {
        t.join();
    }

| Install the scheduling algorithm `shared_ready_queue` in the main thread too, so each new fiber gets launched into the shared pool.
| Launch a number of worker fibers; each worker fiber picks up a character that is passed as parameter to fiber-function `whatevah`. Each worker fiber gets detached.
| Increment fiber counter for each new fiber.
| Launch a couple of threads that join the work sharing.
| sync with other threads: allow them to start processing
| `lock_t` is typedef'ed as `std::unique_lock`< `std::mutex` >
| Suspend main fiber and resume worker fibers in the meanwhile. Main fiber gets resumed (e.g returns from `condition_variable_any::wait()`) if all worker fibers are complete.
| Releasing lock of mtx_count is required before joining the threads, othwerwise the other threads would be blocked inside condition_variable::wait() and would never return (deadlock).
| wait for threads to terminate

The start of the threads is synchronized with a barrier. The main fiber of each thread (including main thread) is suspended until all worker fibers are complete. When the main fiber returns from `condition_variable::wait()`, the thread terminates: the main thread joins all other threads.

    void thread( barrier * b) {
        std::ostringstream buffer;
        buffer << "thread started " << std::this_thread::get_id() << std::endl;
        std::cout << buffer.str() << std::flush;
        boost::fibers::use_scheduling_algorithm< shared_ready_queue >();
        b->wait();
        lock_t lk( mtx_count);
        cnd_count.wait( lk, [](){ return 0 == fiber_count; } );
        BOOST_ASSERT( 0 == fiber_count);
    }

| Install the scheduling algorithm `shared_ready_queue` in order to join the work sharing.
| sync with other threads: allow them to start processing
| Suspend main fiber and resume worker fibers in the meanwhile. Main fiber gets resumed (e.g returns from `condition_variable_any::wait()`) if all worker fibers are complete.

Each worker fiber executes function `whatevah()` with character `me` as parameter. The fiber yields in a loop and prints out a message if it was migrated to another thread.

    void whatevah( char me) {
        try {
            std::thread::id my_thread = std::this_thread::get_id();
            {
                std::ostringstream buffer;
                buffer << "fiber " << me << " started on thread " << my_thread << '\n';
                std::cout << buffer.str() << std::flush;
            }
            for ( unsigned i = 0; i < 10; ++i) {
                boost::this_fiber::yield();
                std::thread::id new_thread = std::this_thread::get_id();
                if ( new_thread != my_thread) {
                    my_thread = new_thread;
                    std::ostringstream buffer;
                    buffer << "fiber " << me << " switched to thread " << my_thread << '\n';
                    std::cout << buffer.str() << std::flush;
                }
            }
        } catch ( ... ) {
        }
        lock_t lk( mtx_count);
        if ( 0 == --fiber_count) {
            lk.unlock();
            cnd_count.notify_all();
        }
    }

| get ID of initial thread
| loop ten times
| yield to other fibers
| get ID of current thread
| test if fiber was migrated to another thread
| Decrement fiber counter for each completed fiber.
| Notify all fibers waiting on `cnd_count`.

###### Scheduling fibers

The fiber scheduler `shared_ready_queue` is like `round_robin`, except that it shares a common ready queue among all participating threads. A thread participates in this pool by executing `use_scheduling_algorithm()` before any other Boost.Fiber operation.

The important point about the ready queue is that it's a class static, common to all instances of shared_ready_queue. Fibers that are enqueued via `sched_algorithm::awakened()` (fibers that are ready to be resumed) are thus available to all threads. It is required to reserve a separate, scheduler-specific queue for the thread's main fiber and dispatcher fibers: these may not be shared between threads! When we're passed either of these fibers, push it there instead of in the shared queue: it would be Bad News for thread B to retrieve and attempt to execute thread A's main fiber.

    virtual void awakened( boost::fibers::context * ctx) noexcept {
        BOOST_ASSERT( nullptr != ctx);

        if ( ctx->is_context( boost::fibers::type::pinned_context) ) {
            local_queue_.push( ctx);
        } else {
            lock_t lk(rqueue_mtx_);
            rqueue_.push( ctx);
        }
    }

| recognize when we're passed this thread's main fiber (or an implicit library helper fiber): never put those on the shared queue
| worker fiber, enqueue on shared queue

When `sched_algorithm::pick_next()` gets called inside one thread, a fiber is dequeued from rqueue_ and will be resumed in that thread.

    virtual boost::fibers::context * pick_next() noexcept {
        boost::fibers::context * ctx( nullptr);
        lock_t lk(rqueue_mtx_);
        if ( ! rqueue_.empty() ) {
            ctx = rqueue_.front();
            rqueue_.pop();
            lk.unlock();
            BOOST_ASSERT( nullptr != ctx);
            boost::fibers::context::active()->migrate( ctx);
        } else {
            lk.unlock();
            if ( ! local_queue_.empty() ) {
                ctx = local_queue_.front();
                local_queue_.pop();
            }
        }
        return ctx;
    }

| pop an item from the ready queue
| attach context to current scheduler via the active fiber of this thread; benign if the fiber already belongs to this thread
| nothing in the ready queue, return main or dispatcher fiber

The source code above is found in work_sharing.cpp.

##### Integrating Fibers with Asynchronous Callbacks

###### Overview

One of the primary benefits of Boost.Fiber is the ability to use asynchronous operations for efficiency, while at the same time structuring the calling code as if the operations were synchronous. Asynchronous operations provide completion notification in a variety of ways, but most involve a callback function of some kind. This section discusses tactics for interfacing Boost.Fiber with an arbitrary async operation.

For purposes of illustration, consider the following hypothetical API:

    class AsyncAPI {
    public:
        // constructor acquires some resource that can be read and written
        AsyncAPI();

        // callbacks accept an int error code; 0 == success
        typedef int errorcode;

        // write callback only needs to indicate success or failure
        void init_write( std::string const& data,
                         std::function< void( errorcode) > const& callback);

        // read callback needs to accept both errorcode and data
        void init_read( std::function< void( errorcode, std::string const&) > const&);

        // ... other operations ...
    };

The significant points about each of `init_write()` and `init_read()` are:

- The `AsyncAPI` method only initiates the operation. It returns immediately, while the requested operation is still pending.
- The method accepts a callback. When the operation completes, the callback is called with relevant parameters (error code, data if applicable).

We would like to wrap these asynchronous methods in functions that appear synchronous by blocking the calling fiber until the operation completes. This lets us use the wrapper function's return value to deliver relevant data.

| Tip
`promise<>` and `future<>` are your friends here.

###### Return Errorcode

The `AsyncAPI::init_write()` callback passes only an `errorcode`. If we simply want the blocking wrapper to return that `errorcode`, this is an extremely straightforward use of `promise<>` and `future<>`:

    AsyncAPI::errorcode write_ec( AsyncAPI & api, std::string const& data) {
        boost::fibers::promise< AsyncAPI::errorcode > promise;
        boost::fibers::future< AsyncAPI::errorcode > future( promise.get_future() );
        // In general, even though we block waiting for future::get() and therefore
        // won't destroy 'promise' until promise::set_value() has been called, we
        // are advised that with threads it's possible for ~promise() to be
        // entered before promise::set_value() has returned. While that shouldn't
        // happen with fibers::promise, a robust way to deal with the lifespan
        // issue is to bind 'promise' into our lambda. Since promise is move-only,
        // use initialization capture.
        api.init_write(
            data,
            [&promise]( AsyncAPI::errorcode ec) mutable {
                                promise.set_value( ec);
                      });
        return future.get();
    }

All we have to do is:

1. Instantiate a `promise<>` of correct type.
2. Obtain its `future<>`.
3. Arrange for the callback to call `promise::set_value()`.
4. Block on `future::get()`.

| Note
This tactic for resuming a pending fiber works even if the callback is called on a different thread than the one on which the initiating fiber is running. In fact, the example program's dummy `AsyncAPI` implementation illustrates that: it simulates async I/O by launching a new thread that sleeps briefly and then calls the relevant callback.

###### Success or Exception

A wrapper more aligned with modern C++ practice would use an exception, rather than an `errorcode`, to communicate failure to its caller. This is straightforward to code in terms of `write_ec()`:

    void write( AsyncAPI & api, std::string const& data) {
        AsyncAPI::errorcode ec = write_ec( api, data);
        if ( ec) {
            throw make_exception("write", ec);
        }
    }

The point is that since each fiber has its own stack, you need not repeat messy boilerplate: normal encapsulation works.

###### Return Errorcode or Data

Things get a bit more interesting when the async operation's callback passes multiple data items of interest. One approach would be to use `std::pair<>` to capture both:

    std::pair< AsyncAPI::errorcode, std::string > read_ec( AsyncAPI & api) {
        typedef std::pair< AsyncAPI::errorcode, std::string > result_pair;
        boost::fibers::promise< result_pair > promise;
        boost::fibers::future< result_pair > future( promise.get_future() );
        // We promise that both 'promise' and 'future' will survive until our
        // lambda has been called.
        api.init_read([&promise]( AsyncAPI::errorcode ec, std::string const& data) mutable {
                                promise.set_value( result_pair( ec, data) );
                      });
        return future.get();
    }

Once you bundle the interesting data in `std::pair<>`, the code is effectively identical to `write_ec()`. You can call it like this:

    std::tie( ec, data) = read_ec( api);

###### Data or Exception

But a more natural API for a function that obtains data is to return only the data on success, throwing an exception on error.

As with `write()` above, it's certainly possible to code a `read()` wrapper in terms of `read_ec()`. But since a given application is unlikely to need both, let's code `read()` from scratch, leveraging `promise::set_exception()`:

    std::string read( AsyncAPI & api) {
        boost::fibers::promise< std::string > promise;
        boost::fibers::future< std::string > future( promise.get_future() );
        // Both 'promise' and 'future' will survive until our lambda has been
        // called.
        api.init_read([&promise]( AsyncAPI::errorcode ec, std::string const& data) mutable {
                               if ( ! ec) {
                                   promise.set_value( data);
                               } else {
                                   promise.set_exception(
                                           std::make_exception_ptr(
                                               make_exception("read", ec) ) );
                               }
                      });
        return future.get();
    }

`future::get()` will do the right thing, either returning `std::string` or throwing an exception.

###### Success/Error Virtual Methods

One classic approach to completion notification is to define an abstract base class with `success()` and `error()` methods. Code wishing to perform async I/O must derive a subclass, override each of these methods and pass the async operation a pointer to a subclass instance. The abstract base class might look like this:

    // every async operation receives a subclass instance of this abstract base
    // class through which to communicate its result
    struct Response {
        typedef std::shared_ptr< Response > ptr;

        // called if the operation succeeds
        virtual void success( std::string const& data) = 0;

        // called if the operation fails
        virtual void error( AsyncAPIBase::errorcode ec) = 0;
    };

Now the `AsyncAPI` operation might look more like this:

    // derive Response subclass, instantiate, pass Response::ptr
    void init_read( Response::ptr);

We can address this by writing a one-size-fits-all `PromiseResponse`:

    class PromiseResponse: public Response {
    public:
        // called if the operation succeeds
        virtual void success( std::string const& data) {
            promise_.set_value( data);
        }

        // called if the operation fails
        virtual void error( AsyncAPIBase::errorcode ec) {
            promise_.set_exception(
                    std::make_exception_ptr(
                        make_exception("read", ec) ) );
        }

        boost::fibers::future< std::string > get_future() {
            return promise_.get_future();
        }

    private:
        boost::fibers::promise< std::string >   promise_;
    };

Now we can simply obtain the `future<>` from that `PromiseResponse` and wait on its `get()`:

    std::string read( AsyncAPI & api) {
        // Because init_read() requires a shared_ptr, we must allocate our
        // ResponsePromise on the heap, even though we know its lifespan.
        auto promisep( std::make_shared< PromiseResponse >() );
        boost::fibers::future< std::string > future( promisep->get_future() );
        // Both 'promisep' and 'future' will survive until our lambda has been
        // called.
        api.init_read( promisep);
        return future.get();
    }

The source code above is found in adapt_callbacks.cpp and adapt_method_calls.cpp.

###### Then There's Boost.Asio

Since the simplest form of Boost.Asio asynchronous operation completion token is a callback function, we could apply the same tactics for Asio as for our hypothetical `AsyncAPI` asynchronous operations.

Fortunately we need not. Boost.Asio incorporates a mechanism[5] by which the caller can customize the notification behavior of every async operation. Therefore we can construct a completion token which, when passed to a Boost.Asio async operation, requests blocking for the calling fiber.

A typical Asio async function might look something like this:[6]

    template < ..., class CompletionToken >
    deduced_return_type
    async_something( ... , CompletionToken&& token)
    {
        // construct handler_type instance from CompletionToken
        handler_type<CompletionToken, ...>::type handler(token);
        // construct async_result instance from handler_type
        async_result<decltype(handler)> result(handler);

        // ... arrange to call handler on completion ...
        // ... initiate actual I/O operation ...

        return result.get();
    }

We will engage that mechanism, which is based on specializing Asio's `handler_type<>` template for the `CompletionToken` type and the signature of the specific callback. The remainder of this discussion will refer back to `async_something()` as the Asio async function under consideration.

The implementation described below uses lower-level facilities than `promise` and `future` for two reasons:

1. The `promise` mechanism interacts badly with `io_service::stop()`. It produces `broken_promise` exceptions.
2. If more than one thread is calling the `io_service::run()` method, the implementation described below allows resuming the suspended fiber on whichever thread gets there first with completion notification. More on this later.

`boost::fibers::asio::yield` is a completion token of this kind. `yield` is an instance of `yield_t`:

    class yield_t {
    public:
        yield_t( bool hop) :
            allow_hop_( hop) {
        }

        /**
         * @code
         * static yield_t yield;
         * boost::system::error_code myec;
         * func(yield[myec]);
         * @endcode
         * @c yield[myec] returns an instance of @c yield_t whose @c ec_ points
         * to @c myec. The expression @c yield[myec] "binds" @c myec to that
         * (anonymous) @c yield_t instance, instructing @c func() to store any
         * @c error_code it might produce into @c myec rather than throwing @c
         * boost::system::system_error.
         */
        yield_t operator[]( boost::system::error_code & ec) const {
            yield_t tmp{ * this };
            tmp.ec_ = & ec;
            return tmp;
        }

    //private:
        // ptr to bound error_code instance if any
        boost::system::error_code   *   ec_{ nullptr };
        // allow calling fiber to "hop" to another thread if it could resume more
        // quickly that way
        bool                            allow_hop_;
    };

`yield_t` is in fact only a placeholder, a way to trigger Boost.Asio customization. It can bind a `boost::system::error_code` for use by the actual handler.

In fact there are two canonical instances of `yield_t` — `yield` and `yield_hop`:

    // canonical instance with allow_hop_ == false
    thread_local yield_t yield{ false };
    // canonical instance with allow_hop_ == true
    thread_local yield_t yield_hop{ true };

We'll get to the differences between these shortly.

Asio customization is engaged by specializing `boost::asio::handler_type<>` for `yield_t`:

    // Handler type specialisation for fibers::asio::yield.
    // When 'yield' is passed as a completion handler which accepts only
    // error_code, use yield_handler<void>. yield_handler will take care of the
    // error_code one way or another.
    template< typename ReturnType >
    struct handler_type< fibers::asio::yield_t, ReturnType( boost::system::error_code) >
    { typedef fibers::asio::detail::yield_handler< void >    type; };

(There are actually four different specializations in detail/yield.hpp, one for each of the four Asio async callback signatures we expect to have to support.)

The above directs Asio to use `yield_handler` as the actual handler for an async operation to which `yield` is passed. There's a generic `yield_handler<T>` implementation and a `yield_handler<void>` specialization. Let's start with the `<void>` specialization:

    // yield_handler<void> is like yield_handler<T> without value_. In fact it's
    // just like yield_handler_base.
    template<>
    class yield_handler< void >: public yield_handler_base {
    public:
        explicit yield_handler( yield_t const& y) :
            yield_handler_base{ y } {
        }

        // nullary completion callback
        void operator()() {
            ( * this)( boost::system::error_code() );
        }

        // inherit operator()(error_code) overload from base class
        using yield_handler_base::operator();
    };

`async_something()`, having consulted the `handler_type<>` traits specialization, instantiates a `yield_handler<void>` to be passed as the actual callback for the async operation. `yield_handler`'s constructor accepts the `yield_t` instance (the `yield` object passed to the async function) and passes it along to `yield_handler_base`:

    // This class encapsulates common elements between yield_handler<T> (capturing
    // a value to return from asio async function) and yield_handler<void> (no
    // such value). See yield_handler<T> and its <void> specialization below. Both
    // yield_handler<T> and yield_handler<void> are passed by value through
    // various layers of asio functions. In other words, they're potentially
    // copied multiple times. So key data such as the yield_completion instance
    // must be stored in our async_result<yield_handler<>> specialization, which
    // should be instantiated only once.
    class yield_handler_base {
    public:
        yield_handler_base( yield_t const& y) :
            // capture the context* associated with the running fiber
            ctx_{ boost::fibers::context::active() },
            // capture the passed yield_t
            yt_{ y } {
        }

        // completion callback passing only (error_code)
        void operator()( boost::system::error_code const& ec) {
            BOOST_ASSERT_MSG( ycomp_,
                              "Must inject yield_completion* "
                              "before calling yield_handler_base::operator()()");
            BOOST_ASSERT_MSG( yt_.ec_,
                              "Must inject boost::system::error_code* "
                              "before calling yield_handler_base::operator()()");
            // If originating fiber is busy testing completed_ flag, wait until it
            // has observed (! completed_).
            yield_completion::lock_t lk{ ycomp_->mtx_ };
            // Notify a subsequent yield_completion::wait() call that it need not
            // suspend.
            ycomp_->completed_ = true;
            // set the error_code bound by yield_t
            * yt_.ec_ = ec;
            // Are we permitted to wake up the suspended fiber on this thread, the
            // thread that called the completion handler?
            if ( ( ! ctx_->is_context( fibers::type::pinned_context) ) && yt_.allow_hop_) {
                // We must not migrate a pinned_context to another thread. If this
                // isn't a pinned_context, and the application passed yield_hop
                // rather than yield, migrate this fiber to the running thread.
                fibers::context::active()->migrate( ctx_);
            }
            // either way, wake the fiber
            fibers::context::active()->set_ready( ctx_);
        }

    //private:
        boost::fibers::context      *   ctx_;
        yield_t                         yt_;
        // We depend on this pointer to yield_completion, which will be injected
        // by async_result.
        yield_completion            *   ycomp_{ nullptr };
    };

`yield_handler_base` stores a copy of the `yield_t` instance — which, as shown above, is only an `error_code` and a `bool`. It also captures the `context`* for the currently-running fiber by calling `context::active()`.

You will notice that `yield_handler_base` has one more data member (`ycomp_`) that is initialized to `nullptr` by its constructor — though its `operator()()` method relies on `ycomp_` being non-null. More on this in a moment.

Having constructed the `yield_handler<void>` instance, `async_something()` goes on to construct an `async_result` specialized for the `handler_type<>::type`: in this case, `async_result<yield_handler<void>>`. It passes the `yield_handler<void>` instance to the new `async_result` instance.

    // Without the need to handle a passed value, our yield_handler<void>
    // specialization is just like async_result_base.
    template<>
    class async_result< boost::fibers::asio::detail::yield_handler< void > > :
        public boost::fibers::asio::detail::async_result_base {
    public:
        typedef void type;

        explicit async_result( boost::fibers::asio::detail::yield_handler< void > & h):
            boost::fibers::asio::detail::async_result_base{ h } {
        }
    };

Naturally that leads us straight to `async_result_base`:

    // Factor out commonality between async_result<yield_handler<T>> and
    // async_result<yield_handler<void>>
    class async_result_base {
    public:
        explicit async_result_base( yield_handler_base & h) {
            // Inject ptr to our yield_completion instance into this
            // yield_handler<>.
            h.ycomp_ = & this->ycomp_;
            // if yield_t didn't bind an error_code, make yield_handler_base's
            // error_code* point to an error_code local to this object so
            // yield_handler_base::operator() can unconditionally store through
            // its error_code*
            if ( ! h.yt_.ec_) {
                h.yt_.ec_ = & ec_;
            }
        }

        void get() {
            // Unless yield_handler_base::operator() has already been called,
            // suspend the calling fiber until that call.
            ycomp_.wait();
            // The only way our own ec_ member could have a non-default value is
            // if our yield_handler did not have a bound error_code AND the
            // completion callback passed a non-default error_code.
            if ( ec_) {
                throw_exception( boost::system::system_error{ ec_ } );
            }
            boost::this_fiber::interruption_point();
        }

    private:
        // If yield_t does not bind an error_code instance, store into here.
        boost::system::error_code       ec_{};
        // async_result_base owns the yield_completion because, unlike
        // yield_handler<>, async_result<> is only instantiated once.
        yield_completion                ycomp_{};
    };

This is how `yield_handler_base::ycomp_` becomes non-null: `async_result_base`'s constructor injects a pointer back to its own `yield_completion` member.

Recall that both of the canonical `yield_t` instances `yield` and `yield_hop` initialize their `error_code*` member `ec_` to `nullptr`. If either of these instances is passed to `async_something()` (`ec_` is still `nullptr`), the copy stored in `yield_handler_base` will likewise have null `ec_`. `async_result_base`'s constructor sets `yield_handler_base`'s `yield_t`'s `ec_` member to point to its own `error_code` member.

The stage is now set. `async_something()` initiates the actual async operation, arranging to call its `yield_handler<void>` instance on completion. Let's say, for the sake of argument, that the actual async operation's callback has signature `void(error_code)`.

But since it's an async operation, control returns at once to `async_something()`. `async_something()` calls `async_result<yield_handler<void>>::get()`, and will return its return value.

`async_result<yield_handler<void>>::get()` inherits `async_result_base::get()`.

`async_result_base::get()` immediately calls `yield_completion::wait()`.

    // Bundle a completion bool flag with a spinlock to protect it.
    struct yield_completion {
        typedef fibers::detail::spinlock    mutex_t;
        typedef std::unique_lock< mutex_t > lock_t;

        mutex_t mtx_{};
        bool    completed_{ false };

        void wait() {
            // yield_handler_base::operator()() will set completed_ true and
            // attempt to wake a suspended fiber. It would be Bad if that call
            // happened between our detecting (! completed_) and suspending.
            lock_t lk{ mtx_ };
            // If completed_ is already set, we're done here: don't suspend.
            if ( ! completed_) {
                // suspend(unique_lock<spinlock>) unlocks the lock in the act of
                // resuming another fiber
                fibers::context::active()->suspend( lk);
            }
        }
    };

Supposing that the pending async operation has not yet completed, `yield_completion::completed_` will still be `false`, and `wait()` will call `context::suspend()` on the currently-running fiber.

Other fibers will now have a chance to run.

Some time later, the async operation completes. It calls `yield_handler<void>::operator()(error_code const&)` with an `error_code` indicating either success or failure. We'll consider both cases.

`yield_handler<void>` explicitly inherits `operator()(error_code const&)` from `yield_handler_base`.

`yield_handler_base::operator()(error_code const&)` first sets `yield_completion::completed_` `true`. This way, if `async_something()`'s async operation completes immediately — if `yield_handler_base::operator()` is called even before `async_result_base::get()` — the calling fiber will not suspend.

The actual `error_code` produced by the async operation is then stored through the stored `yield_t::ec_` pointer. If `async_something()`'s caller used (e.g.) `yield[my_ec]` to bind a local `error_code` instance, the actual `error_code` value is stored into the caller's variable. Otherwise, it is stored into `async_result_base::ec_`.

Finally we get to the distinction between `yield` and `yield_hop`.

As described for `context::is_context()`, a `pinned_context` fiber is special to the library and must never be passed to `context::migrate()`. We must detect and avoid that case here.

The `yield_t::allow_hop_` `bool` indicates whether `async_something()`'s caller is willing to allow the running fiber to “hop” to another thread (`yield_hop`) or whether s/he insists that the fiber resume on the same thread (`yield`).

If the caller passed `yield_hop` to `async_something()`, and the running fiber isn't a `pinned_context`, `yield_handler_base::operator()` passes the `context` of the original fiber — the one on which `async_something()` was called, captured in `yield_handler_base`'s constructor — to the current thread's `context::migrate()`.

If the running application has more than one thread calling `io_service::run()`, that fiber could return from `async_something()` on a different thread (the one calling `yield_handler_base::operator()`) than the one on which it entered `async_something()`.

In any case, the fiber is marked as ready to run by passing it to `context::set_ready()`. Control then returns from `yield_handler_base::operator()`: the callback is done.

In due course, the fiber `yield_handler_base::ctx_` is resumed. Control returns from `context::suspend()` to `yield_completion::wait()`, which returns to `async_result_base::get()`.

- If the original caller passed `yield[my_ec]` to `async_something()` to bind a local `error_code` instance, then `yield_handler_base::operator()` stored its `error_code` to the caller's `my_ec` instance, leaving `async_result_base::ec_` initialized to success.
- If the original caller passed `yield` to `async_something()` without binding a local `error_code` variable, then `yield_handler_base::operator()` stored its `error_code` into `async_result_base::ec_`. If in fact that `error_code` is success, then all is well.
- Otherwise — the original caller did not bind a local `error_code` and `yield_handler_base::operator()` was called with an `error_code` indicating error — `async_result_base::get()` throws `system_error` with that `error_code`.

The case in which `async_something()`'s completion callback has signature `void()` is similar. `yield_handler<void>::operator()()` invokes the machinery above with a “success” `error_code`.

A completion callback with signature `void(error_code, T)` (that is: in addition to `error_code`, callback receives some data item) is handled somewhat differently. For this kind of signature, `handler_type<>::type` specifies `yield_handler<T>` (for `T` other than `void`).

A `yield_handler<T>` reserves a `value_` pointer to a value of type `T`:

    // asio uses handler_type<completion token type, signature>::type to decide
    // what to instantiate as the actual handler. Below, we specialize
    // handler_type< yield_t, ... > to indicate yield_handler<>. So when you pass
    // an instance of yield_t as an asio completion token, asio selects
    // yield_handler<> as the actual handler class.
    template< typename T >
    class yield_handler: public yield_handler_base {
    public:
        // asio passes the completion token to the handler constructor
        explicit yield_handler( yield_t const& y) :
            yield_handler_base{ y } {
        }

        // completion callback passing only value (T)
        void operator()( T t) {
            // just like callback passing success error_code
            (*this)( boost::system::error_code(), std::move(t) );
        }

        // completion callback passing (error_code, T)
        void operator()( boost::system::error_code const& ec, T t) {
            BOOST_ASSERT_MSG( value_,
                              "Must inject value ptr "
                              "before caling yield_handler<T>::operator()()");
            // move the value to async_result<> instance BEFORE waking up a
            // suspended fiber
            * value_ = std::move( t);
            // forward the call to base-class completion handler
            yield_handler_base::operator()( ec);
        }

    //private:
        // pointer to destination for eventual value
        // this must be injected by async_result before operator()() is called
        T                           *   value_{ nullptr };
    };

This pointer is initialized to `nullptr`.

When `async_something()` instantiates `async_result<yield_handler<T>>`:

    // asio constructs an async_result<> instance from the yield_handler specified
    // by handler_type<>::type. A particular asio async method constructs the
    // yield_handler, constructs this async_result specialization from it, then
    // returns the result of calling its get() method.
    template< typename T >
    class async_result< boost::fibers::asio::detail::yield_handler< T > > :
        public boost::fibers::asio::detail::async_result_base {
    public:
        // type returned by get()
        typedef T type;

        explicit async_result( boost::fibers::asio::detail::yield_handler< T > & h) :
            boost::fibers::asio::detail::async_result_base{ h } {
            // Inject ptr to our value_ member into yield_handler<>: result will
            // be stored here.
            h.value_ = & value_;
        }

        // asio async method returns result of calling get()
        type get() {
            boost::fibers::asio::detail::async_result_base::get();
            return std::move( value_);
        }

    private:
        type                            value_{};
    };

this `async_result<>` specialization reserves a member of type `T` to receive the passed data item, and sets `yield_handler<T>::value_` to point to its own data member.

`async_result<yield_handler<T>>` overrides `get()`. The override calls `async_result_base::get()`, so the calling fiber suspends as described above.

`yield_handler<T>::operator()(error_code, T)` stores its passed `T` value into `async_result<yield_handler<T>>::value_`.

Then it passes control to `yield_handler_base::operator()(error_code)` to deal with waking (and possibly migrating) the original fiber as described above.

When `async_result<yield_handler<T>>::get()` resumes, it returns the stored `value_` to `async_something()` and ultimately to `async_something()`'s caller.

The case of a callback signature `void(T)` is handled by having `yield_handler<T>::operator()(T)` engage the `void(error_code, T)` machinery, passing a “success” `error_code`.

The source code above is found in yield.hpp and detail/yield.hpp.

##### Integrating Fibers with Nonblocking I/O

###### Overview

Nonblocking I/O is distinct from asynchronous I/O. A true async I/O operation promises to initiate the operation and notify the caller on completion, usually via some sort of callback (as described in Integrating Fibers with Asynchronous Callbacks).

In contrast, a nonblocking I/O operation refuses to start at all if it would be necessary to block, returning an error code such as `EWOULDBLOCK`. The operation is performed only when it can complete immediately. In effect, the caller must repeatedly retry the operation until it stops returning `EWOULDBLOCK`.

In a classic event-driven program, it can be something of a headache to use nonblocking I/O. At the point where the nonblocking I/O is attempted, a return value of `EWOULDBLOCK` requires the caller to pass control back to the main event loop, arranging to retry again on the next iteration.

Worse, a nonblocking I/O operation might partially succeed. That means that the relevant business logic must continue receiving control on every main loop iteration until all required data have been processed: a doubly-nested loop, implemented as a callback-driven state machine.

Boost.Fiber can simplify this problem immensely. Once you have integrated with the application's main loop as described in Sharing a Thread with Another Main Loop, waiting for the next main-loop iteration is as simple as calling `this_fiber::yield()`.

###### Example Nonblocking API

For purposes of illustration, consider this API:

    class NonblockingAPI {
    public:
        NonblockingAPI();

        // nonblocking operation: may return EWOULDBLOCK
        int read( std::string & data, std::size_t desired);

        ...
    };

###### Polling for Completion

We can build a low-level wrapper around `NonblockingAPI::read()` that shields its caller from ever having to deal with `EWOULDBLOCK`:

    // guaranteed not to return EWOULDBLOCK
    int read_chunk( NonblockingAPI & api, std::string & data, std::size_t desired) {
        int error;
        while ( EWOULDBLOCK == ( error = api.read( data, desired) ) ) {
            // not ready yet -- try again on the next iteration of the
            // application's main loop
            boost::this_fiber::yield();
        }
        return error;
    }

###### Filling All Desired Data

Given `read_chunk()`, we can straightforwardly iterate until we have all desired data:

    // keep reading until desired length, EOF or error
    // may return both partial data and nonzero error
    int read_desired( NonblockingAPI & api, std::string & data, std::size_t desired) {
        // we're going to accumulate results into 'data'
        data.clear();
        std::string chunk;
        int error = 0;
        while ( data.length() < desired &&
               ( error = read_chunk( api, chunk, desired - data.length() ) ) == 0) {
            data.append( chunk);
        }
        return error;
    }

(Of course there are more efficient ways to accumulate string data. That's not the point of this example.)

###### Wrapping it Up

Finally, we can define a relevant exception:

    // exception class augmented with both partially-read data and errorcode
    class IncompleteRead : public std::runtime_error {
    public:
        IncompleteRead( std::string const& what, std::string const& partial, int ec) :
            std::runtime_error( what),
            partial_( partial),
            ec_( ec) {
        }

        std::string get_partial() const {
            return partial_;
        }

        int get_errorcode() const {
            return ec_;
        }

    private:
        std::string partial_;
        int         ec_;
    };

and write a simple `read()` function that either returns all desired data or throws `IncompleteRead`:

    // read all desired data or throw IncompleteRead
    std::string read( NonblockingAPI & api, std::size_t desired) {
        std::string data;
        int ec( read_desired( api, data, desired) );

        // for present purposes, EOF isn't a failure
        if ( 0 == ec || EOF == ec) {
            return data;
        }

        // oh oh, partial read
        std::ostringstream msg;
        msg << "NonblockingAPI::read() error " << ec << " after "
            << data.length() << " of " << desired << " characters";
        throw IncompleteRead( msg.str(), data, ec);
    }

Once we can transparently wait for the next main-loop iteration using `this_fiber::yield()`, ordinary encapsulation Just Works.

The source code above is found in adapt_nonblocking.cpp.

##### when_any / when_all functionality

###### Overview

A bit of wisdom from the early days of computing still holds true today: prefer to model program state using the instruction pointer rather than with Boolean flags. In other words, if the program must “do something” and then do something almost the same, but with minor changes... perhaps parts of that something should be broken out as smaller separate functions, rather than introducing flags to alter the internal behavior of a monolithic function.

To that we would add: prefer to describe control flow using C++ native constructs such as function calls, `if`, `while`, `for`, `do` et al. rather than as chains of callbacks.

One of the great strengths of Boost.Fiber is the flexibility it confers on the coder to restructure an application from chains of callbacks to straightforward C++ statement sequence, even when code in that fiber is in fact interleaved with code running in other fibers.

There has been much recent discussion about the benefits of when_any and when_all functionality. When dealing with asynchronous and possibly unreliable services, these are valuable idioms. But of course when_any and when_all are closely tied to the use of chains of callbacks.

This section presents recipes for achieving the same ends, in the context of a fiber that wants to “do something” when one or more other independent activities have completed. Accordingly, these are `wait_something()` functions rather than `when_something()` functions. The expectation is that the calling fiber asks to launch those independent activities, then waits for them, then sequentially proceeds with whatever processing depends on those results.

The function names shown (e.g. `wait_first_simple()`) are for illustrative purposes only, because all these functions have been bundled into a single source file. Presumably, if (say) `wait_first_success()` best suits your application needs, you could introduce that variant with the name `wait_any()`.

| Note
The functions presented in this section accept variadic argument lists of task functions. Corresponding `wait_something()` functions accepting a container of task functions are left as an exercise for the interested reader. Those should actually be simpler. Most of the complexity would arise from overloading the same name for both purposes.

All the source code for this section is found in wait_stuff.cpp.

###### Example Task Function

We found it convenient to model an asynchronous task using this function:

    template< typename T >
    T sleeper_impl( T item, int ms, bool thrw = false) {
        std::ostringstream descb, funcb;
        descb << item;
        std::string desc( descb.str() );
        funcb << "  sleeper(" << item << ")";
        Verbose v( funcb.str() );

        boost::this_fiber::sleep_for( std::chrono::milliseconds( ms) );
        if ( thrw) {
            throw std::runtime_error( desc);
        }
        return item;
    }

with type-specific `sleeper()` “front ends” for `std::string`, `double` and `int`.

`Verbose` simply prints a message to `std::cout` on construction and destruction.

Basically:

1. `sleeper()` prints a start message;
2. sleeps for the specified number of milliseconds;
3. if `thrw` is passed as `true`, throws a string description of the passed `item`;
4. else returns the passed `item`.
5. On the way out, `sleeper()` produces a stop message.

This function will feature in the example calls to the various functions presented below.

###### when_any

###### when_any, simple completion

The simplest case is when you only need to know that the first of a set of asynchronous tasks has completed — but you don't need to obtain a return value, and you're confident that they will not throw exceptions.

For this we introduce a `Done` class to wrap a `bool` variable with a `condition_variable` and a `mutex`:

    // Wrap canonical pattern for condition_variable + bool flag
    struct Done {
    private:
        boost::fibers::condition_variable   cond;
        boost::fibers::mutex                mutex;
        bool                                ready = false;

    public:
        typedef std::shared_ptr< Done >     ptr;

        void wait() {
            std::unique_lock< boost::fibers::mutex > lock( mutex);
            cond.wait( lock, [this](){ return ready; });
        }

        void notify() {
            {
                std::unique_lock< boost::fibers::mutex > lock( mutex);
                ready = true;
            } // release mutex
            cond.notify_one();
        }
    };

The pattern we follow throughout this section is to pass a `std::shared_ptr<>` to the relevant synchronization object to the various tasks' fiber functions. This eliminates nagging questions about the lifespan of the synchronization object relative to the last of the fibers.

`wait_first_simple()` uses that tactic for `Done`:

    template< typename ... Fns >
    void wait_first_simple( Fns && ... functions) {
        // Use shared_ptr because each function's fiber will bind it separately,
        // and we're going to return before the last of them completes.
        auto done( std::make_shared< Done >() );
        wait_first_simple_impl( done, std::forward< Fns >( functions) ... );
        done->wait();
    }

`wait_first_simple_impl()` is an ordinary recursion over the argument pack, capturing `Done::ptr` for each new fiber:

    // Degenerate case: when there are no functions to wait for, return
    // immediately.
    void wait_first_simple_impl( Done::ptr) {
    }

    // When there's at least one function to wait for, launch it and recur to
    // process the rest.
    template< typename Fn, typename ... Fns >
    void wait_first_simple_impl( Done::ptr done, Fn && function, Fns && ... functions) {
        boost::fibers::fiber( [done, function](){
                                  function();
                                  done->notify();
                              }).detach();
        wait_first_simple_impl( done, std::forward< Fns >( functions) ... );
    }

The body of the fiber's lambda is extremely simple, as promised: call the function, notify `Done` when it returns. The first fiber to do so allows `wait_first_simple()` to return — which is why it's useful to have `std::shared_ptr<Done>` manage the lifespan of our `Done` object rather than declaring it as a stack variable in `wait_first_simple()`.

This is how you might call it:

    wait_first_simple(
            [](){ sleeper("wfs_long",   150); },
            [](){ sleeper("wfs_medium", 100); },
            [](){ sleeper("wfs_short",   50); });

In this example, control resumes after `wait_first_simple()` when `sleeper("wfs_short", 50)` completes — even though the other two `sleeper()` fibers are still running.

###### when_any, return value

It seems more useful to add the ability to capture the return value from the first of the task functions to complete. Again, we assume that none will throw an exception.

One tactic would be to adapt our `Done` class to store the first of the return values, rather than a simple `bool`. However, we choose instead to use a `unbounded_channel<>`. We'll only need to enqueue the first value, so we'll `unbounded_channel::close()` it once we've retrieved that value. Subsequent `push()` calls will return `closed`.

    // Assume that all passed functions have the same return type. The return type
    // of wait_first_value() is the return type of the first passed function. It is
    // simply invalid to pass NO functions.
    template< typename Fn, typename ... Fns >
    typename std::result_of< Fn() >::type
    wait_first_value( Fn && function, Fns && ... functions) {
        typedef typename std::result_of< Fn() >::type return_t;
        typedef boost::fibers::unbounded_channel< return_t > channel_t;
        auto channelp( std::make_shared< channel_t >() );
        // launch all the relevant fibers
        wait_first_value_impl< return_t >( channelp,
                                           std::forward< Fn >( function),
                                           std::forward< Fns >( functions) ... );
        // retrieve the first value
        return_t value( channelp->value_pop() );
        // close the channel: no subsequent push() has to succeed
        channelp->close();
        return value;
    }

The meat of the `wait_first_value_impl()` function is as you might expect:

    template< typename T, typename Fn >
    void wait_first_value_impl( std::shared_ptr< boost::fibers::unbounded_channel< T > > channel,
                                Fn && function) {
        boost::fibers::fiber( [channel, function](){
                                  // Ignore channel_op_status returned by push():
                                  // might be closed; we simply don't care.
                                  channel->push( function() );
                              }).detach();
    }

It calls the passed function, pushes its return value and ignores the `push()` result. You might call it like this:

    std::string result = wait_first_value(
            [](){ return sleeper("wfv_third",  150); },
            [](){ return sleeper("wfv_second", 100); },
            [](){ return sleeper("wfv_first",   50); });
    std::cout << "wait_first_value() => " << result << std::endl;
    assert(result == "wfv_first");

###### when_any, produce first outcome, whether result or exception

We may not be running in an environment in which we can guarantee no exception will be thrown by any of our task functions. In that case, the above implementations of `wait_first_something()` would be naïve: as mentioned in the section on Fiber Management, an uncaught exception in one of our task fibers would cause `std::terminate()` to be called.

Let's at least ensure that such an exception would propagate to the fiber awaiting the first result. We can use `future<>` to transport either a return value or an exception. Therefore, we will change `wait_first_value()`'s `unbounded_channel<>` to hold `future< T >` items instead of simply `T`.

Once we have a `future<>` in hand, all we need do is call `future::get()`, which will either return the value or rethrow the exception.

    template< typename Fn, typename ... Fns >
    typename std::result_of< Fn() >::type
    wait_first_outcome( Fn && function, Fns && ... functions) {
        // In this case, the value we pass through the channel is actually a
        // future -- which is already ready. future can carry either a value or an
        // exception.
        typedef typename std::result_of< Fn() >::type return_t;
        typedef boost::fibers::future< return_t > future_t;
        typedef boost::fibers::unbounded_channel< future_t > channel_t;
        auto channelp(std::make_shared< channel_t >() );
        // launch all the relevant fibers
        wait_first_outcome_impl< return_t >( channelp,
                                             std::forward< Fn >( function),
                                             std::forward< Fns >( functions) ... );
        // retrieve the first future
        future_t future( channelp->value_pop() );
        // close the channel: no subsequent push() has to succeed
        channelp->close();
        // either return value or throw exception
        return future.get();
    }

So far so good — but there's a timing issue. How should we obtain the `future<>` to `unbounded_channel::push()` on the channel?

We could call `fibers::async()`. That would certainly produce a `future<>` for the task function. The trouble is that it would return too quickly! We only want `future<>` items for completed tasks on our `unbounded_channel<>`. In fact, we only want the `future<>` for the one that completes first. If each fiber launched by `wait_first_outcome()` were to `push()` the result of calling `async()`, the channel would only ever report the result of the leftmost task item — not the one that completes most quickly.

Calling `future::get()` on the future returned by `async()` wouldn't be right. You can only call `get()` once per `future<>` instance! And if there were an exception, it would be rethrown inside the helper fiber at the producer end of the channel, rather than propagated to the consumer end.

We could call `future::wait()`. That would block the helper fiber until the `future<>` became ready, at which point we could `push()` it to be retrieved by `wait_first_outcome()`.

That would work — but there's a simpler tactic that avoids creating an extra fiber. We can wrap the task function in a `packaged_task<>`. While one naturally thinks of passing a `packaged_task<>` to a new fiber — that is, in fact, what `async()` does — in this case, we're already running in the helper fiber at the producer end of the channel! We can simply call the `packaged_task<>`. On return from that call, the task function has completed, meaning that the `future<>` obtained from the `packaged_task<>` is certain to be ready. At that point we can simply `push()` it to the channel.

    template< typename T, typename CHANNELP, typename Fn >
    void wait_first_outcome_impl( CHANNELP channel, Fn && function) {
        boost::fibers::fiber(
            // Use std::bind() here for C++11 compatibility. C++11 lambda capture
            // can't move a move-only Fn type, but bind() can. Let bind() move the
            // channel pointer and the function into the bound object, passing
            // references into the lambda.
            std::bind(
                []( CHANNELP & channel,
                    typename std::decay< Fn >::type & function) {
                    // Instantiate a packaged_task to capture any exception thrown by
                    // function.
                    boost::fibers::packaged_task< T() > task( function);
                    // Immediately run this packaged_task on same fiber. We want
                    // function() to have completed BEFORE we push the future.
                    task();
                    // Pass the corresponding future to consumer. Ignore
                    // channel_op_status returned by push(): might be closed; we
                    // simply don't care.
                    channel->push( task.get_future() );
                },
                channel,
                std::forward< Fn >( function)
            )).detach();
    }

Calling it might look like this:

    std::string result = wait_first_outcome(
            [](){ return sleeper("wfos_first",   50); },
            [](){ return sleeper("wfos_second", 100); },
            [](){ return sleeper("wfos_third",  150); });
    std::cout << "wait_first_outcome(success) => " << result << std::endl;
    assert(result == "wfos_first");

    std::string thrown;
    try {
        result = wait_first_outcome(
                [](){ return sleeper("wfof_first",   50, true); },
                [](){ return sleeper("wfof_second", 100); },
                [](){ return sleeper("wfof_third",  150); });
    } catch ( std::exception const& e) {
        thrown = e.what();
    }
    std::cout << "wait_first_outcome(fail) threw '" << thrown
              << "'" << std::endl;
    assert(thrown == "wfof_first");

###### when_any, produce first success

One scenario for “when_any” functionality is when we're redundantly contacting some number of possibly-unreliable web services. Not only might they be slow — any one of them might produce a failure rather than the desired result.

In such a case, `wait_first_outcome()` isn't the right approach. If one of the services produces an error quickly, while another follows up with a real answer, we don't want to prefer the error just because it arrived first!

Given the `unbounded_channel< future< T > >` we already constructed for `wait_first_outcome()`, though, we can readily recast the interface function to deliver the first successful result.

That does beg the question: what if all the task functions throw an exception? In that case we'd probably better know about it.

The C++ Parallelism Draft Technical Specification proposes a `std::exception_list` exception capable of delivering a collection of `std::exception_ptr`s. Until that becomes universally available, let's fake up an `exception_list` of our own:

    class exception_list : public std::runtime_error {
    public:
        exception_list( std::string const& what) :
            std::runtime_error( what) {
        }

        typedef std::vector< std::exception_ptr >   bundle_t;

        // N4407 proposed std::exception_list API
        typedef bundle_t::const_iterator iterator;

        std::size_t size() const noexcept {
            return bundle_.size();
        }

        iterator begin() const noexcept {
            return bundle_.begin();
        }

        iterator end() const noexcept {
            return bundle_.end();
        }

        // extension to populate
        void add( std::exception_ptr ep) {
            bundle_.push_back( ep);
        }

    private:
        bundle_t bundle_;
    };

Now we can build `wait_first_success()`, using `wait_first_outcome_impl()`.

Instead of retrieving only the first `future<>` from the channel, we must now loop over `future<>` items. Of course we must limit that iteration! If we launch only `count` producer fibers, the `(count+1)` st `unbounded_channel::pop()` call would block forever.

Given a ready `future<>`, we can distinguish failure by calling `future::get_exception_ptr()`. If the `future<>` in fact contains a result rather than an exception, `get_exception_ptr()` returns `nullptr`. In that case, we can confidently call `future::get()` to return that result to our caller.

If the `std::exception_ptr` is not `nullptr`, though, we collect it into our pending `exception_list` and loop back for the next `future<>` from the channel.

If we fall out of the loop — if every single task fiber threw an exception — we throw the `exception_list` exception into which we've been collecting those `std::exception_ptr`s.

    template< typename Fn, typename ... Fns >
    typename std::result_of< Fn() >::type
    wait_first_success( Fn && function, Fns && ... functions) {
        std::size_t count( 1 + sizeof ... ( functions) );
        // In this case, the value we pass through the channel is actually a
        // future -- which is already ready. future can carry either a value or an
        // exception.
        typedef typename std::result_of< typename std::decay< Fn >::type() >::type return_t;
        typedef boost::fibers::future< return_t > future_t;
        typedef boost::fibers::unbounded_channel< future_t > channel_t;
        auto channelp( std::make_shared< channel_t >() );
        // launch all the relevant fibers
        wait_first_outcome_impl< return_t >( channelp,
                                             std::forward< Fn >( function),
                                             std::forward< Fns >( functions) ... );
        // instantiate exception_list, just in case
        exception_list exceptions("wait_first_success() produced only errors");
        // retrieve up to 'count' results -- but stop there!
        for ( std::size_t i = 0; i < count; ++i) {
            // retrieve the next future
            future_t future( channelp->value_pop() );
            // retrieve exception_ptr if any
            std::exception_ptr error( future.get_exception_ptr() );
            // if no error, then yay, return value
            if ( ! error) {
                // close the channel: no subsequent push() has to succeed
                channelp->close();
                // show caller the value we got
                return future.get();
            }

            // error is non-null: collect
            exceptions.add( error);
        }
        // We only arrive here when every passed function threw an exception.
        // Throw our collection to inform caller.
        throw exceptions;
    }

A call might look like this:

    std::string result = wait_first_success(
                [](){ return sleeper("wfss_first",   50, true); },
                [](){ return sleeper("wfss_second", 100); },
                [](){ return sleeper("wfss_third",  150); });
    std::cout << "wait_first_success(success) => " << result << std::endl;
    assert(result == "wfss_second");

###### when_any, heterogeneous types

We would be remiss to ignore the case in which the various task functions have distinct return types. That means that the value returned by the first of them might have any one of those types. We can express that with Boost.Variant.

To keep the example simple, we'll revert to pretending that none of them can throw an exception. That makes `wait_first_value_het()` strongly resemble `wait_first_value()`. We can actually reuse `wait_first_value_impl()`, merely passing `boost::variant<T0, T1, ...>` as the channel's value type rather than the common `T`!

Naturally this could be extended to use `wait_first_success()` semantics instead.

    // No need to break out the first Fn for interface function: let the compiler
    // complain if empty.
    // Our functions have different return types, and we might have to return any
    // of them. Use a variant, expanding std::result_of<Fn()>::type for each Fn in
    // parameter pack.
    template< typename ... Fns >
    boost::variant< typename std::result_of< Fns() >::type ... >
    wait_first_value_het( Fns && ... functions) {
        // Use unbounded_channel<boost::variant<T1, T2, ...>>; see remarks above.
        typedef boost::variant< typename std::result_of< Fns() >::type ... > return_t;
        typedef boost::fibers::unbounded_channel< return_t > channel_t;
        auto channelp( std::make_shared< channel_t >() );
        // launch all the relevant fibers
        wait_first_value_impl< return_t >( channelp,
                                           std::forward< Fns >( functions) ... );
        // retrieve the first value
        return_t value( channelp->value_pop() );
        // close the channel: no subsequent push() has to succeed
        channelp->close();
        return value;
    }

It might be called like this:

    boost::variant< std::string, double, int > result =
        wait_first_value_het(
                [](){ return sleeper("wfvh_third",  150); },
                [](){ return sleeper(3.14,          100); },
                [](){ return sleeper(17,             50); });
    std::cout << "wait_first_value_het() => " << result << std::endl;
    assert(boost::get< int >( result) == 17);

###### when_any, a dubious alternative

Certain topics in C++ can arouse strong passions, and exceptions are no exception. We cannot resist mentioning — for purely informational purposes — that when you need only the first result from some number of concurrently-running fibers, it would be possible to pass a `shared_ptr< `promise<>`>` to the participating fibers, then cause the initiating fiber to call `future::get()` on its `future<>`. The first fiber to call `promise::set_value()` on that shared `promise` will succeed; subsequent `set_value()` calls on the same `promise` instance will throw `future_error`.

Use this information at your own discretion. Beware the dark side.

###### when_all functionality

###### when_all, simple completion

For the case in which we must wait for all task functions to complete — but we don't need results (or expect exceptions) from any of them — we can write `wait_all_simple()` that looks remarkably like `wait_first_simple()`. The difference is that instead of our `Done` class, we instantiate a `barrier` and call its `barrier::wait()`.

We initialize the `barrier` with `(count+1)` because we are launching `count` fibers, plus the `wait()` call within `wait_all_simple()` itself.

    template< typename ... Fns >
    void wait_all_simple( Fns && ... functions) {
        std::size_t count( sizeof ... ( functions) );
        // Initialize a barrier(count+1) because we'll immediately wait on it. We
        // don't want to wake up until 'count' more fibers wait on it. Even though
        // we'll stick around until the last of them completes, use shared_ptr
        // anyway because it's easier to be confident about lifespan issues.
        auto barrier( std::make_shared< boost::fibers::barrier >( count + 1) );
        wait_all_simple_impl( barrier, std::forward< Fns >( functions) ... );
        barrier->wait();
    }

As stated above, the only difference between `wait_all_simple_impl()` and `wait_first_simple_impl()` is that the former calls `barrier::wait()` rather than `Done::notify()`:

    template< typename Fn, typename ... Fns >
    void wait_all_simple_impl( std::shared_ptr< boost::fibers::barrier > barrier,
                               Fn && function, Fns && ... functions) {
        boost::fibers::fiber(
                std::bind(
                    []( std::shared_ptr< boost::fibers::barrier > & barrier,
                        typename std::decay< Fn >::type & function) mutable {
                            function();
                            barrier->wait();
                    },
                    barrier,
                    std::forward< Fn >( function)
                )).detach();
        wait_all_simple_impl( barrier, std::forward< Fns >( functions) ... );
    }

You might call it like this:

    wait_all_simple(
            [](){ sleeper("was_long",   150); },
            [](){ sleeper("was_medium", 100); },
            [](){ sleeper("was_short",   50); });

Control will not return from the `wait_all_simple()` call until the last of its task functions has completed.

###### when_all, return values

As soon as we want to collect return values from all the task functions, we can see right away how to reuse `wait_first_value()`'s channel<T> for the purpose. All we have to do is avoid closing it after the first value!

But in fact, collecting multiple values raises an interesting question: do we really want to wait until the slowest of them has arrived? Wouldn't we rather process each result as soon as it becomes available?

Fortunately we can present both APIs. Let's define `wait_all_values_source()` to return `shared_ptr<unbounded_channel<T>>`.[7]

Given `wait_all_values_source()`, it's straightforward to implement `wait_all_values()`:

    template< typename Fn, typename ... Fns >
    std::vector< typename std::result_of< Fn() >::type >
    wait_all_values( Fn && function, Fns && ... functions) {
        std::size_t count( 1 + sizeof ... ( functions) );
        typedef typename std::result_of< Fn() >::type return_t;
        typedef std::vector< return_t > vector_t;
        vector_t results;
        results.reserve( count);

        // get channel
        std::shared_ptr< boost::fibers::unbounded_channel< return_t > > channel =
            wait_all_values_source( std::forward< Fn >( function),
                                    std::forward< Fns >( functions) ... );
        // fill results vector
        return_t value;
        while ( boost::fibers::channel_op_status::success == channel->pop(value) ) {
            results.push_back( value);
        }
        // return vector to caller
        return results;
    }

It might be called like this:

    std::vector< std::string > values =
        wait_all_values(
                [](){ return sleeper("wav_late",   150); },
                [](){ return sleeper("wav_middle", 100); },
                [](){ return sleeper("wav_early",   50); });

As you can see from the loop in `wait_all_values()`, instead of requiring its caller to count values, we define `wait_all_values_source()` to `unbounded_channel::close()` the channel when done. But how do we do that? Each producer fiber is independent. It has no idea whether it is the last one to `unbounded_channel::push()` a value.

We can address that problem with a counting façade for the `unbounded_channel<>`. In fact, our façade need only support the producer end of the channel.

    // Introduce a channel facade that closes the channel once a specific number
    // of items has been pushed. This allows an arbitrary consumer to read until
    // 'closed' without itself having to count items.
    template< typename T >
    class nchannel {
    public:
        nchannel( std::shared_ptr< boost::fibers::unbounded_channel< T > > cp,
                  std::size_t lm):
            channel_( cp),
            limit_( lm) {
            assert(channel_);
            if ( 0 == limit_) {
                channel_->close();
            }
        }

        boost::fibers::channel_op_status push( T && va) {
            boost::fibers::channel_op_status ok =
                channel_->push( std::forward< T >( va) );
            if ( ok == boost::fibers::channel_op_status::success &&
                 --limit_ == 0) {
                // after the 'limit_'th successful push, close the channel
                channel_->close();
            }
            return ok;
        }

    private:
        std::shared_ptr< boost::fibers::unbounded_channel< T > >    channel_;
        std::size_t                                                 limit_;
    };

Armed with `nchannel<>`, we can implement `wait_all_values_source()`. It starts just like `wait_first_value()`. The difference is that we wrap the `unbounded_channel<T>` with an `nchannel<T>` to pass to the producer fibers.

Then, of course, instead of popping the first value, closing the channel and returning it, we simply return the `shared_ptr<unbounded_channel<T>>`.

    // Return a shared_ptr<unbounded_channel<T>> from which the caller can
    // retrieve each new result as it arrives, until 'closed'.
    template< typename Fn, typename ... Fns >
    std::shared_ptr< boost::fibers::unbounded_channel< typename std::result_of< Fn() >::type > >
    wait_all_values_source( Fn && function, Fns && ... functions) {
        std::size_t count( 1 + sizeof ... ( functions) );
        typedef typename std::result_of< Fn() >::type return_t;
        typedef boost::fibers::unbounded_channel< return_t > channel_t;
        // make the channel
        auto channelp( std::make_shared< channel_t >() );
        // and make an nchannel facade to close it after 'count' items
        auto ncp( std::make_shared< nchannel< return_t > >( channelp, count) );
        // pass that nchannel facade to all the relevant fibers
        wait_all_values_impl< return_t >( ncp,
                                          std::forward< Fn >( function),
                                          std::forward< Fns >( functions) ... );
        // then return the channel for consumer
        return channelp;
    }

For example:

    std::shared_ptr< boost::fibers::unbounded_channel< std::string > > channel =
        wait_all_values_source(
                [](){ return sleeper("wavs_third",  150); },
                [](){ return sleeper("wavs_second", 100); },
                [](){ return sleeper("wavs_first",   50); });
    std::string value;
    while ( boost::fibers::channel_op_status::success == channel->pop(value) ) {
        std::cout << "wait_all_values_source() => '" << value
                  << "'" << std::endl;
    }

`wait_all_values_impl()` really is just like `wait_first_value_impl()` except for the use of `nchannel<T>` rather than `unbounded_channel<T>`:

    template< typename T, typename Fn >
    void wait_all_values_impl( std::shared_ptr< nchannel< T > > channel,
                               Fn && function) {
        boost::fibers::fiber( [channel, function](){
                                  channel->push(function());
                              }).detach();
    }

###### when_all until first exception

Naturally, just as with `wait_first_outcome()`, we can elaborate `wait_all_values()` and `wait_all_values_source()` by passing `future< T >` instead of plain `T`.

`wait_all_until_error()` pops that `future< T >` and calls its `future::get()`:

    template< typename Fn, typename ... Fns >
    std::vector< typename std::result_of< Fn() >::type >
    wait_all_until_error( Fn && function, Fns && ... functions) {
        std::size_t count( 1 + sizeof ... ( functions) );
        typedef typename std::result_of< Fn() >::type return_t;
        typedef typename boost::fibers::future< return_t > future_t;
        typedef std::vector< return_t > vector_t;
        vector_t results;
        results.reserve( count);

        // get channel
        std::shared_ptr<
            boost::fibers::unbounded_channel< future_t > > channel(
                wait_all_until_error_source( std::forward< Fn >( function),
                                             std::forward< Fns >( functions) ... ) );
        // fill results vector
        future_t future;
        while ( boost::fibers::channel_op_status::success == channel->pop( future) ) {
            results.push_back( future.get() );
        }
        // return vector to caller
        return results;
    }

For example:

    std::string thrown;
    try {
        std::vector< std::string > values = wait_all_until_error(
                [](){ return sleeper("waue_late",   150); },
                [](){ return sleeper("waue_middle", 100, true); },
                [](){ return sleeper("waue_early",   50); });
    } catch ( std::exception const& e) {
        thrown = e.what();
    }
    std::cout << "wait_all_until_error(fail) threw '" << thrown
              << "'" << std::endl;

Naturally this complicates the API for `wait_all_until_error_source()`. The caller must both retrieve a `future< T >` and call its `get()` method. It would, of course, be possible to return a façade over the consumer end of the channel that would implicitly perform the `get()` and return a simple `T` (or throw).

The implementation is just as you would expect. Notice, however, that we can reuse `wait_first_outcome_impl()`, passing the `nchannel<T>` rather than `unbounded_channel<T>`.

    // Return a shared_ptr<unbounded_channel<future<T>>> from which the caller can
    // get() each new result as it arrives, until 'closed'.
    template< typename Fn, typename ... Fns >
    std::shared_ptr<
        boost::fibers::unbounded_channel<
            boost::fibers::future<
                typename std::result_of< Fn() >::type > > >
    wait_all_until_error_source( Fn && function, Fns && ... functions) {
        std::size_t count( 1 + sizeof ... ( functions) );
        typedef typename std::result_of< Fn() >::type return_t;
        typedef boost::fibers::future< return_t > future_t;
        typedef boost::fibers::unbounded_channel< future_t > channel_t;
        // make the channel
        auto channelp( std::make_shared< channel_t >() );
        // and make an nchannel facade to close it after 'count' items
        auto ncp( std::make_shared< nchannel< future_t > >( channelp, count) );
        // pass that nchannel facade to all the relevant fibers
        wait_first_outcome_impl< return_t >( ncp,
                                             std::forward< Fn >( function),
                                             std::forward< Fns >( functions) ... );
        // then return the channel for consumer
        return channelp;
    }

For example:

    typedef boost::fibers::future< std::string > future_t;
    std::shared_ptr< boost::fibers::unbounded_channel< future_t > > channel =
        wait_all_until_error_source(
                [](){ return sleeper("wauess_third",  150); },
                [](){ return sleeper("wauess_second", 100); },
                [](){ return sleeper("wauess_first",   50); });
    future_t future;
    while ( boost::fibers::channel_op_status::success == channel->pop( future) ) {
        std::string value( future.get() );
        std::cout << "wait_all_until_error_source(success) => '" << value
                  << "'" << std::endl;
    }

###### wait_all, collecting all exceptions

Given `wait_all_until_error_source()`, it might be more reasonable to make a `wait_all_...()` that collects all errors instead of presenting only the first:

    template< typename Fn, typename ... Fns >
    std::vector< typename std::result_of< Fn() >::type >
    wait_all_collect_errors( Fn && function, Fns && ... functions) {
        std::size_t count( 1 + sizeof ... ( functions) );
        typedef typename std::result_of< Fn() >::type return_t;
        typedef typename boost::fibers::future< return_t > future_t;
        typedef std::vector< return_t > vector_t;
        vector_t results;
        results.reserve( count);
        exception_list exceptions("wait_all_collect_errors() exceptions");

        // get channel
        std::shared_ptr<
            boost::fibers::unbounded_channel< future_t > > channel(
                wait_all_until_error_source( std::forward< Fn >( function),
                                             std::forward< Fns >( functions) ... ) );
        // fill results and/or exceptions vectors
        future_t future;
        while ( boost::fibers::channel_op_status::success == channel->pop( future) ) {
            std::exception_ptr exp = future.get_exception_ptr();
            if ( ! exp) {
                results.push_back( future.get() );
            } else {
                exceptions.add( exp);
            }
        }
        // if there were any exceptions, throw
        if ( exceptions.size() ) {
            throw exceptions;
        }
        // no exceptions: return vector to caller
        return results;
    }

The implementation is a simple variation on `wait_first_success()`, using the same `exception_list` exception class.

###### when_all, heterogeneous types

But what about the case when we must wait for all results of different types?

We can present an API that is frankly quite cool. Consider a sample struct:

    struct Data {
        std::string str;
        double      inexact;
        int         exact;

        friend std::ostream& operator<<( std::ostream& out, Data const& data);
        ...
    };

Let's fill its members from task functions all running concurrently:

    Data data = wait_all_members< Data >(
            [](){ return sleeper("wams_left", 100); },
            [](){ return sleeper(3.14,        150); },
            [](){ return sleeper(17,          50); });
    std::cout << "wait_all_members<Data>(success) => " << data << std::endl;

Note that for this case, we abandon the notion of capturing the earliest result first, and so on: we must fill exactly the passed struct in left-to-right order.

That permits a beautifully simple implementation:

    // Explicitly pass Result. This can be any type capable of being initialized
    // from the results of the passed functions, such as a struct.
    template< typename Result, typename ... Fns >
    Result wait_all_members( Fns && ... functions) {
        // Run each of the passed functions on a separate fiber, passing all their
        // futures to helper function for processing.
        return wait_all_members_get< Result >(
                boost::fibers::async( std::forward< Fns >( functions) ) ... );
    }

    template< typename Result, typename ... Futures >
    Result wait_all_members_get( Futures && ... futures) {
        // Fetch the results from the passed futures into Result's initializer
        // list. It's true that the get() calls here will block the implicit
        // iteration over futures -- but that doesn't matter because we won't be
        // done until the slowest of them finishes anyway. As results are
        // processed in argument-list order rather than order of completion, the
        // leftmost get() to throw an exception will cause that exception to
        // propagate to the caller.
        return Result{ futures.get() ... };
    }

It is tempting to try to implement `wait_all_members()` as a one-liner like this:

    return Result{ boost::fibers::async(functions).get()... };

The trouble with this tactic is that it would serialize all the task functions. The runtime makes a single pass through `functions`, calling `fibers::async()` for each and then immediately calling `future::get()` on its returned `future<>`. That blocks the implicit loop. The above is almost equivalent to writing:

    return Result{ functions()... };

in which, of course, there is no concurrency at all.

Passing the argument pack through a function-call boundary (`wait_all_members_get()`) forces the runtime to make two passes: one in `wait_all_members()` to collect the `future<>`s from all the `async()` calls, the second in `wait_all_members_get()` to fetch each of the results.

As noted in comments, within the `wait_all_members_get()` parameter pack expansion pass, the blocking behavior of `get()` becomes irrelevant. Along the way, we will hit the `get()` for the slowest task function; after that every subsequent `get()` will complete in trivial time.

By the way, we could also use this same API to fill a vector or other collection:

    // If we don't care about obtaining results as soon as they arrive, and we
    // prefer a result vector in passed argument order rather than completion
    // order, wait_all_members() is another possible implementation of
    // wait_all_until_error().
    auto strings = wait_all_members< std::vector< std::string > >(
            [](){ return sleeper("wamv_left",   150); },
            [](){ return sleeper("wamv_middle", 100); },
            [](){ return sleeper("wamv_right",   50); });
    std::cout << "wait_all_members<vector>() =>";
    for ( std::string const& str : strings) {
        std::cout << " '" << str << "'";
    }
    std::cout << std::endl;

##### Sharing a Thread with Another Main Loop

###### Overview

As always with cooperative concurrency, it is important not to let any one fiber monopolize the processor too long: that could “starve” other ready fibers. This section discusses a couple of solutions.

###### Event-Driven Program

Consider a classic event-driven program, organized around a main loop that fetches and dispatches incoming I/O events. You are introducing Boost.Fiber because certain asynchronous I/O sequences are logically sequential, and for those you want to write and maintain code that looks and acts sequential.

You are launching fibers on the application's main thread because certain of their actions will affect its user interface, and the application's UI framework permits UI operations only on the main thread. Or perhaps those fibers need access to main-thread data, and it would be too expensive in runtime (or development time) to robustly defend every such data item with thread synchronization primitives.

You must ensure that the application's main loop itself doesn't monopolize the processor: that the fibers it launches will get the CPU cycles they need.

The solution is the same as for any fiber that might claim the CPU for an extended time: introduce calls to `this_fiber::yield()`. The most straightforward approach is to call `yield()` on every iteration of your existing main loop. In effect, this unifies the application's main loop with Boost.Fiber's internal main loop. `yield()` allows the fiber manager to run any fibers that have become ready since the previous iteration of the application's main loop. When these fibers have had a turn, control passes to the thread's main fiber, which returns from `yield()` and resumes the application's main loop.

###### Integrating with Boost.Asio

More challenging is when the application's main loop is embedded in some other library or framework. Such an application will typically, after performing all necessary setup, pass control to some form of `run()` function from which control does not return until application shutdown.

A Boost.Asio program might call `io_service::run()` in this way.

The trick here is to arrange to pass control to `this_fiber::yield()` frequently. You can use an Asio timer for this purpose. Instantiate the timer, arranging to call a handler function when the timer expires:

[run_service]

The handler function calls `yield()`, then resets the timer and arranges to wake up again on expiration:

[timer_handler]

Then instead of directly calling `io_service::run()`, your application would call the above `run_service(io_service&)` wrapper.

Since, in this example, we always pass control to the fiber manager via `yield()`, the calling fiber is never blocked. Therefore there is always at least one ready fiber. Therefore the fiber manager never sleeps.

Using `std::chrono::seconds(0)` for every keepalive timer interval would be unfriendly to other threads. When all I/O is pending and all fibers are blocked, the io_service and the fiber manager would simply spin the CPU, passing control back and forth to each other. Resetting the timer for `keepalive_iterval` allows tuning the responsiveness of this thread relative to others in the same way as when Boost.Fiber is running without Boost.Asio.

The source code above is found in round_robin.hpp.

##### Performance

Performance measurements were taken using `std::chrono::highresolution_clock`, with overhead corrections. The code was compiled using the build options: variant = release, optimization = speed [8].

The columns labeled fiber (atomics) were compiled with default fiber synchronization, capable of synchronizing fibers running on different threads. The columns labeled fiber (raw) were compiled with `BOOST_FIBERS_NO_ATOMICS`.

Table 1.1. Overhead of join (contains fiber-context destruction, fiber-stack deallocation)

thread | fiber (atomics) | fiber (raw) | tbb | qthread
--- | --- | --- | --- | ---
18 µs | 950 ns | 900 ns | 570 ns | 620 ns

(from overhead_join.cpp)

Table 1.2. Overhead of detach

thread | fiber (atomics) | fiber (raw)
--- | --- | ---
126 ns | 21 ns | 20 ns

(from overhead_detach.cpp)

Table 1.3. Overhead of yield

thread | fiber (atomics) | fiber (raw)
--- | --- | ---
1.5 µs | 310 ns | 330 ns

(from overhead_yield.cpp)

Table 1.4. Overhead of waiting on a future

thread | fiber (atomics) | fiber (raw)
--- | --- | ---
16 µs | 1.40 µs | 1.38 µs

(from overhead_future.cpp)

Table 1.5. Overhead of fiber creation (contains fiber-stack allocation and preparation, fiber-context construction, scheduler handling)

thread | fiber (atomics) | fiber (raw)
--- | --- | ---
18 µs | 450 ns | 445 ns

(from overhead_create.cpp)

Table 1.6. Scaling of creating and joining

average of | thread | fiber (atomics) | fiber (raw)
--- | --- | --- | ---
10 | 8.21 µs | 1.96 µs | 1.85 µs
50 | 6.67 µs | 1.40 µs | 1.27 µs
100 | 6.79 µs | 1.84 µs | 1.81 µs
500 | 8.25 µs | 1.13 µs | 1.10 µs
1000 | 7.71 µs | 1.46 µs | 1.26 µs
5000 | 5.67 µs | 2.11 µs | 1.90 µs
10000 | 5.25 µs | 2.36 µs | 1.89 µs

(from scale_join.cpp)

Numbers of the microbenchmark syknet from Alexander Temerev [9]:

Table 1.7. performance of N=100000 actors/goroutines/fibers

Haskell | stack-1.0.4 | fiber (single threaded/raw) | gcc-5.2.1 | fiber (single threaded/atomics) | gcc-5.2.1 | Erlang | erts-7.0 | Go | go1.4.2
--- | --- | --- | --- | ---
58ms - 108ms | 205ms - 263ms | 221ms - 278ms | 237ms- 470ms | 614ms - 883ms

##### Customization

###### Overview

As noted in the Scheduling section, by default Boost.Fiber uses its own `round_robin` scheduler for each thread. To control the way Boost.Fiber schedules ready fibers on a particular thread, in general you must follow several steps. This section discusses those steps, whereas Scheduling serves as a reference for the classes involved.

The library's fiber manager keeps track of suspended (blocked) fibers. Only when a fiber becomes ready to run is it passed to the scheduler. Of course, if there are fewer than two ready fibers, the scheduler's job is trivial. Only when there are two or more ready fibers does the particular scheduler implementation start to influence the overall sequence of fiber execution.

In this section we illustrate a simple custom scheduler that honors an integer fiber priority. We will implement it such that a fiber with higher priority is preferred over a fiber with lower priority. Any fibers with equal priority values are serviced on a round-robin basis.

The full source code for the examples below is found in priority.cpp.

###### Custom Property Class

The first essential point is that we must associate an integer priority with each fiber.[10]

One might suggest deriving a custom `fiber` subclass to store such properties. There are a couple of reasons for the present mechanism.

1. Boost.Fiber provides a number of different ways to launch a fiber. (Consider `fibers::async()`.) Higher-level libraries might introduce additional such wrapper functions. A custom scheduler must associate its custom properties with every fiber in the thread, not only the ones explicitly launched by instantiating a custom `fiber` subclass.
2. Consider a large existing program that launches fibers in many different places in the code. We discover a need to introduce a custom scheduler for a particular thread. If supporting that scheduler's custom properties required a particular `fiber` subclass, we would have to hunt down and modify every place that launches a fiber on that thread.
3. The `fiber` class is actually just a handle to internal `context` data. A subclass of `fiber` would not add data to `context`.

The present mechanism allows you to “drop in” a custom scheduler with its attendant custom properties without altering the rest of your application.

Instead of deriving a custom scheduler fiber properties subclass from `fiber`, you must instead derive it from `fiber_properties`.

    class priority_props : public boost::fibers::fiber_properties {
    public:
        priority_props( boost::fibers::context * ctx):
            fiber_properties( ctx),
            priority_( 0) {
        }

        int get_priority() const {
            return priority_;
        }

        // Call this method to alter priority, because we must notify
        // priority_scheduler of any change.
        void set_priority( int p) {
            // Of course, it's only worth reshuffling the queue and all if we're
            // actually changing the priority.
            if ( p != priority_) {
                priority_ = p;
                notify();
            }
        }

        // The fiber name of course is solely for purposes of this example
        // program; it has nothing to do with implementing scheduler priority.
        // This is a public data member -- not requiring set/get access methods --
        // because we need not inform the scheduler of any change.
        std::string name;
    private:
        int priority_;
    };

| Your subclass constructor must accept a ``context`*` and pass it to the `fiber_properties` constructor.
| Provide read access methods at your own discretion.
| It's important to call `notify()` on any change in a property that can affect the scheduler's behavior. Therefore, such modifications should only be performed through an access method.
| A property that does not affect the scheduler does not need access methods.

###### Custom Scheduler Class

Now we can derive a custom scheduler from `sched_algorithm_with_properties<>`, specifying our custom property class `priority_props` as the template parameter.

    class priority_scheduler :
        public boost::fibers::sched_algorithm_with_properties< priority_props > {
    private:
        typedef boost::fibers::scheduler::ready_queue_t   rqueue_t;

        rqueue_t                                rqueue_;
        std::mutex                  mtx_{};
        std::condition_variable     cnd_{};
        bool                        flag_{ false };

    public:
        priority_scheduler() :
            rqueue_() {
        }

        // For a subclass of sched_algorithm_with_properties<>, it's important to
        // override the correct awakened() overload.
        virtual void awakened( boost::fibers::context * ctx, priority_props & props) noexcept {
            int ctx_priority = props.get_priority();
            // With this scheduler, fibers with higher priority values are
            // preferred over fibers with lower priority values. But fibers with
            // equal priority values are processed in round-robin fashion. So when
            // we're handed a new context*, put it at the end of the fibers
            // with that same priority. In other words: search for the first fiber
            // in the queue with LOWER priority, and insert before that one.
            rqueue_t::iterator i( std::find_if( rqueue_.begin(), rqueue_.end(),
                [ctx_priority,this]( boost::fibers::context & c)
                { return properties( &c ).get_priority() < ctx_priority; }));
            // Now, whether or not we found a fiber with lower priority,
            // insert this new fiber here.
            rqueue_.insert( i, * ctx);
        }

        virtual boost::fibers::context * pick_next() noexcept {
            // if ready queue is empty, just tell caller
            if ( rqueue_.empty() ) {
                return nullptr;
            }
            boost::fibers::context * ctx( & rqueue_.front() );
            rqueue_.pop_front();
            return ctx;
        }

        virtual bool has_ready_fibers() const noexcept {
            return ! rqueue_.empty();
        }

        virtual void property_change( boost::fibers::context * ctx, priority_props & props) noexcept {
            // Although our priority_props class defines multiple properties, only
            // one of them (priority) actually calls notify() when changed. The
            // point of a property_change() override is to reshuffle the ready
            // queue according to the updated priority value.

            // 'ctx' might not be in our queue at all, if caller is changing the
            // priority of (say) the running fiber. If it's not there, no need to
            // move it: we'll handle it next time it hits awakened().
            if ( ! ctx->ready_is_linked()) {
                return;
            }

            // Found ctx: unlink it
            ctx->ready_unlink();

            // Here we know that ctx was in our ready queue, but we've unlinked
            // it. We happen to have a method that will (re-)add a context* to the
            // right place in the ready queue.
            awakened( ctx, props);
        }

        void suspend_until( std::chrono::steady_clock::time_point const& time_point) noexcept {
            if ( (std::chrono::steady_clock::time_point::max)() == time_point) {
                std::unique_lock< std::mutex > lk( mtx_);
                cnd_.wait( lk, [this](){ return flag_; });
                flag_ = false;
            } else {
                std::unique_lock< std::mutex > lk( mtx_);
                cnd_.wait_until( lk, time_point, [this](){ return flag_; });
                flag_ = false;
            }
        }

        void notify() noexcept {
            std::unique_lock< std::mutex > lk( mtx_);
            flag_ = true;
            lk.unlock();
            cnd_.notify_all();
        }
    };

| See ready_queue_t.
| You must override the `sched_algorithm_with_properties::awakened()` method. This is how your scheduler receives notification of a fiber that has become ready to run.
| `props` is the instance of priority_props associated with the passed fiber `ctx`.
| You must override the `sched_algorithm_with_properties::pick_next()` method. This is how your scheduler actually advises the fiber manager of the next fiber to run.
| You must override `sched_algorithm_with_properties::has_ready_fibers()` to inform the fiber manager of the state of your ready queue.
| Overriding `sched_algorithm_with_properties::property_change()` is optional. This override handles the case in which the running fiber changes the priority of another ready fiber: a fiber already in our queue. In that case, move the updated fiber within the queue.
| Your `property_change()` override must be able to handle the case in which the passed `ctx` is not in your ready queue. It might be running, or it might be blocked.

Our example `priority_scheduler` doesn't override `sched_algorithm_with_properties::new_properties()`: we're content with allocating `priority_props` instances on the heap.

###### Replace Default Scheduler

You must call `use_scheduling_algorithm()` at the start of each thread on which you want Boost.Fiber to use your custom scheduler rather than its own default `round_robin`. Specifically, you must call `use_scheduling_algorithm()` before performing any other Boost.Fiber operations on that thread.

    int main( int argc, char *argv[]) {
        // make sure we use our priority_scheduler rather than default round_robin
        boost::fibers::use_scheduling_algorithm< priority_scheduler >();
        ...
    }

###### Use Properties

The running fiber can access its own `fiber_properties` subclass instance by calling `this_fiber::properties()`. Although `properties<>()` is a nullary function, you must pass, as a template parameter, the `fiber_properties` subclass.

    boost::this_fiber::properties< priority_props >().name = "main";

Given a `fiber` instance still connected with a running fiber (that is, not `fiber::detach()`ed), you may access that fiber's properties using `fiber::properties()`. As with `this_fiber::properties<>()`, you must pass your `fiber_properties` subclass as the template parameter.

    template< typename Fn >
    boost::fibers::fiber launch( Fn && func, std::string const& name, int priority) {
        boost::fibers::fiber fiber( func);
        priority_props & props( fiber.properties< priority_props >() );
        props.name = name;
        props.set_priority( priority);
        return fiber;
    }

Launching a new fiber schedules that fiber as ready, but does not immediately enter its fiber-function. The current fiber retains control until it blocks (or yields, or terminates) for some other reason. As shown in the `launch()` function above, it is reasonable to launch a fiber and immediately set relevant properties -- such as, for instance, its priority. Your custom scheduler can then make use of this information next time the fiber manager calls `sched_algorithm_with_properties::pick_next()`.

##### Rationale

###### 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.[11].

###### 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.

###### 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 this description.)

###### spurious wakeup

Spurious wakeup can happen when using `std::condition_variable`: the condition variable appears to be have been signaled while the awaited condition may still be false. Spurious wakeup can happen repeatedly and is caused on some multiprocessor systems where making `std::condition_variable` wakeup completely predictable would slow down all `std::condition_variable` operations.[12]

`condition_variable` is not subject to spurious wakeup. Nonetheless it is prudent to test the business-logic condition in a `wait()` loop — or, equivalently, use one of the `wait( lock, predicate )` overloads.

See also No Spurious Wakeups.

###### migrating fibers between threads

Support for migrating fibers between threads has been integrated. The user-defined scheduler must call `context::migrate()` on a fiber-context on the destination thread, passing `migrate()` the fiber-context to migrate. (For more information about custom schedulers, see Customization.) Examples `work_sharing` and `work_stealing` in directory `examples` might be used as a blueprint.

See also Migrating fibers between threads.

###### 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 Sharing a Thread with Another Main Loop. To interface smoothly with an arbitrary Asio async I/O operation, see Then There's Boost.Asio.

###### tested compilers

The library was tested with GCC-5.1.1, Clang-3.6.0 and MSVC-14.0 in c++11-mode.

###### supported architectures

Boost.Fiber depends on Boost.Context - the list of supported architectures can be found here.

##### Acknowledgments

I'd like to thank Agustín Bergé, Eugene Yakubovich, Giovanni Piero Deretta and especially Nat Goodspeed.

##### Appendix: Installing and Running Tests

###### Installing the Fiber library

As Fiber is not yet officially part of Boost, it is necessary to embed it in an existing Boost source tree.

The downloaded Fiber library can be placed into an existing Boost source tree by moving the top-level Fiber directory to `libs/fiber` under the top-level Boost directory, then further moving `libs/fiber/include/boost/fiber` (in other words, the Fiber library's `include/boost/fiber` directory) to `boost/fiber` under the top-level Boost directory.

On a Posix system such as Linux or OS X, you may use symlinks instead.

Create a symlink from the Boost directory's `libs/fiber` to the top-level Fiber directory, e.g.:

    cd ~/boost_1_61_0
    ln -s ~/boost-fiber-master libs/fiber

Then create a symlink from the Boost directory's `boost/fiber` to the Fiber library's `include/boost/fiber` directory:

    cd boost
    ln -s ../libs/fiber/include/boost/fiber fiber

For some versions of the Boost.Build system, it was important to use a relative symlink of that form for `boost/fiber`.

###### Running Tests

Once the Fiber library has been overlaid (or symlinked) into the Boost source tree this way, the Boost.Build system can build it like any other Boost library. In particular:

    cd ~/boost_1_61_0
    ./bootstrap.sh
    ./b2 libs/fiber/test

On Windows, the commands would look more like:

    cd /D %HOMEDRIVE%%HOMEPATH%\boost_1_61_0
    bootstrap
    b2 libs\fiber\test

[2] The current implementation wakes fibers in FIFO order: the first to call `wait()` wakes first, and so forth. But it is perilous to rely on the order in which the various fibers will reach the `wait()` call.

[3] The “main” fiber on each thread, that is, the fiber on which the thread is launched, cannot migrate to any other thread. Also Boost.Fiber implicitly creates a dispatcher fiber for each thread — this cannot migrate either.

[4] Of course it would be problematic to migrate a fiber that relies on thread-local storage.

[5] This mechanism has been proposed as a conventional way to allow the caller of an async function to specify completion handling: N4045.

[6] per N4045

[7] We could have used either `bounded_channel<>` or `unbounded_channel<>`. We chose `unbounded_channel<>` on the assumption that its simpler semantics imply a cheaper implementation.

[8] Intel Core2 Q6700, x86_64, 3GHz

[9] Intel Core2 Q6700, x86_64, 3GHz

[10] A previous version of the Fiber library implicitly tracked an int priority for each fiber, even though the default scheduler ignored it. This has been dropped, since the library now supports arbitrary scheduler-specific fiber properties.

[11] 'N4024: Distinguishing coroutines and fibers'

[12] David R. Butenhof “Programming with POSIX Threads”