On 8/31/2015 4:17 PM, Thomas Heller wrote:
On 08/31/2015 06:53 PM, Niall Douglas wrote:
On 31 Aug 2015 at 16:50, Thomas Heller wrote: None of those get wait() called on them, and therefore you very rarely block. As an example, if you executed 1000 promise + future + continuations but blocked on just one of those, my condition "future.wait() very rarely blocks in your use scenario" is fulfilled by virtue that future.wait() is simply never called.
Looks like a problem with my english, sorry, I am not a native speaker. Let's see if I got it correct now: "Your code rarely calls future<T>::wait to avoid blocking because that is usually costly".
From my experience that holds true for any future implementation (be it based on OS synchronization primitives or user level context based synchronization), and is probably the number one reason why one would want something like future<T>::then, when_all and friends.
So I take it that this requirement is nothing special to your lightweight futures.
My interpretation (which could of course be wrong) is that the "lightweight future" implementation of `wait` does busy-waiting because there is nowhere to store a `condition_variable`, so a spinlock is used instead. There is no technical reason for that to be the case. A spinlock is still a perfectly adequate choice for a future implementation, given that there's very little concurrent access to the shared state. That doesn't rule out yielding the thread/cpu while waiting. An implementation could use a thread-local `condition_variable` and have the future point to it while it waits. This is not necessarily a good approach, but it is simple and should do as a proof of concept. Again, I could just be misinterpreting things. Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com