Boost logo

Boost :

Subject: Re: [boost] [next gen futures] Lightweight monad ready for inspection
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-06-20 08:21:50

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
> >
> > 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.


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at