On 20 Jun 2015 at 12:44, Avi Kivity wrote:
On 06/19/2015 08:03 PM, Niall Douglas wrote:
Some may remember the thread starting from http://boost.2283326.n4.nabble.com/next-gen-future-promise-What-to-cal l-the-monadic-return-type-td4676039.html and that I would firstly prepare an optimally lightweight monad<T> for review here before going on to base a next-gen lightweight future-promise on that monad<T>.
BOOST_SPINLOCK_FUTURE_MSVC_HELP future_type get_future() { // If no value stored yet, I need locks on from now on if(!_need_locks && _storage.type==value_storage_type::storage_type::empty) { _need_locks=true; new (&_lock) spinlock<bool>(); }
Isn't that the common case? Usually if you already have a value, you return it with make_ready_future(). Otherwise, at the time of get_future(), the promise still doesn't have a value.
This came up in the discussion a month ago with some feeling that this was a pointless optimisation. I disagree for the same reasons I outlined back then, just because you should use make_ready_future() doesn't mean in generic programming you always can. A very good example of that is in the WG21 coroutines proposal where if the operations are correctly ordered and if you never enter a suspend point, the compiler can set the promise before getting the future and therefore its optimiser can completely elide the promise-future construct entirely. I've already raised that idea with Gor as a non-compiler-magic way of completely eliding future-promise overheads in the non-suspending coroutine outcome. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/