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: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-07-06 06:21:19

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/