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

Subject: Re: [boost] Boost.Fiber mini-review September 4-13
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2015-09-04 15:14:05

On 09/04/2015 08:54 PM, Oliver Kowalke wrote:
> 2015-09-04 20:10 GMT+02:00 Giovanni Piero Deretta <gpderetta_at_[hidden]>:
>
>> - Boost.Fiber is yet another library that comes with its own future
>> type. For the sake of interoperability, the author should really
>> contribute changes to boost.thread so that its futures can be re-used.
>>
>
> boost::fibers::future<> has to use internally boost::fibers::mutex instead
> of std::mutex/boost::mutex (utilizing
> for instance pthread_mutex) as boost.thread does.
> boost::fibers::mutex is based on atomics - it does not block the thread -
> instead the runing fiber is suspended
> and another fiber will be resumed.
> a possible future implementation - usable for boost.thread + boost.fiber -
> must offer to customize the mutex type.
> futures from boost.thread as well as boost.fiber are allocating futures,
> e.g. the share-state is allocated on the free-store.
> I planed to provide non-allocating future as suggested by Tony Van Eerd.
> Fortunately Niall has already implemented it (boost.spinlock/boost.monad) -
> no mutex is required.
> If boost.monad is accepted in boost I'll to integrate it in boost.fiber.

Could you please elaborate a bit why non-allocating futures wouldn't 
require a mutex? Or more generally, a execution context suspension/yield 
mechanism?