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

On 4 Sep 2015 8:09 pm, "Oliver Kowalke" wrote:

2015-09-04 21:14 GMT+02:00 Thomas Heller :

Could you please elaborate a bit why non-allocating futures wouldn't

...

require a mutex? Or more generally, a execution context suspension/yield mechanism?

I mean no std::mutex (pthread_mutex) is required. a protocol, utilizing atomics, between future and promise does the job - http://blog.forecode.com/2012/05/23/a-non-allocating-stdfuturepromise/ in 'void promise::set_value(R && r)' boost::this_fiber::yield() could be used, if the future is not ready yet (e.g. AS(future->state, 0, 'R')

fails).

That's not really what I meant though. I believe that a future can be implemented efficiently without any internal mutex or condition variable (which would relegated only to the wait side). A spin lock might be needed to implement a tiny critical session in 'then' or 'wait' for shared_futures, but that's it. Such a future would work well as the underlying implementation for boost::thread::future or boost::fiber::future, which would only need to override the wait implementation and would still allow both futures to interoperate. My suggestion is to convince Vicente to implement such functionality in Boost.Thread. -- gpd