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

https://github.com/boostcon/cppnow_presentations_2013/blob/master/mon/future... 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 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 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 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