1 Jul
2015
1 Jul
'15
11:39 p.m.
On 1/07/2015 22:29, Niall Douglas wrote:
What you are missing is that we assume that whoever is calling get_future() must issue some form of memory synchronisation to transmit the newly constructed future to another thread. That synchronises the changed _needs_locks to other threads. I suppose it is possible that someone could send the future to one thread, and have a different thread do a state read and in theory the state reading thread doesn't see any new state.
The most common case is to transport the promise to another thread (sometimes via packaged_task) and to return the future on the calling thread. I suppose designs that pass the future to another thread instead are possible but they seem a lot weirder and more convoluted.