Re: [boost] Non-allocating future promise... Re: ASIO into the standard (was: Re: C++ committee meeting report)

Subject: Re: [boost] Non-allocating future promise... Re: ASIO into the standard (was: Re: C++ committee meeting report)
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2014-07-07 01:50:54

https://github.com/boostcon/cppnow_presentations_2013/blob/master/mon/future_promise.pdf?raw=true

2013.  The talk is called "Non-Allocating std::future/promise".  I
think most of it is about a... non-allocating future-promise.
Hopefully. That was at least the idea.

In brief:
- each has a pointer to the other
- the result is stored in the future
- if one moves or is destroyed, it is... tricky. But basically a CAS
and a small spin lock in a rare case when you need to wait for the
other side to update the pointer.

Yes, replacing the spin and pointer updating with TM would be nice.

Pretty much all my code fits on one (crowded) slide near the end of
the presentation.

Tony

On Sun, Jul 6, 2014 at 6:21 AM, Niall Douglas <s_sourceforge_at_[hidden]> wrote:
> On 6 Jul 2014 at 5:20, Gottlob Frege wrote:
>
>> Niall, is your non-allocating future promise going to borrow from my C++Now
>> slides, or are you trying a different direction?
>
> You proposed a non-allocating future promise at C++ Now???
>
> I just rechecked your slides and I see nothing related? Can you
> supply me some detail?
>
> The direction I was going to take was to extend proposed
> std::experimental::optional<E, T> as the value store which would also
> allow Vicente's monadic framework to interop seamlessly with future
> promise. The promise and future would be tied together with two
> atomically updated pointers. As much as it is very straightforward,
> what has diverted me is that my attempt used memory transactions (I
> tried both __transaction_atomic and Intel TSX) and their performance
> greatly surprised me, as I think it probably did to the other devs on
> Boost.Thread who I CC-ied privately.
>
> I then resolved to learn a feel for memory transactions as I clearly
> didn't have the experience, so for the past two weeks I have been
> implementing a concurrent_unordered_map<K, T> based on memory
> transactions. My first attempt was a simple forward linked list which
> worked well up until the load factor went past about four, at which
> point performance collapsed. So the current attempt is based on a
> table design where if the transaction is unavailable, it uses the
> bottom bit of the pointer to the value as a fallback spinlock as is
> required by Intel TSX.
>
> Debugging it has been slow going, not helped by this sort of work
> being hard to mentally gear into after a day of work plus Clara had
> her vaccinations this past week, which hasn't made for much sleep.
> I'll get there eventually and probably find the traditional split
> order list method of implementing concurrent_unordered_map is far
> faster :( (though, to be honest, I cannot currently see how that
> would be possible as split order lists are not as cache friendly as
> what I am doing).
>
> Niall
>
> --
> ned Productions Limited Consulting
> http://www.nedproductions.biz/
> http://ie.linkedin.com/in/nialldouglas/
>
>
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost