On 26 May 2015 2:32 pm, "Peter Dimov"
Giovanni Piero Deretta wrote:
You need to protect concurrent calls to then...
Hm, good point, I hadn't thought of that.
Note however that if remove promise::get_future and create a
promise/future pair in one go, I can then in principle check that the future is unique and omit the mutex lock.
Yes, also it is feasible to chain all callbacks in a lock free lists as there are no deletions until signal time. Doesn't work for wait any and timed waits when waiters enter and leave all the time. Also it might me desirable to to unify the waiter list and the callback list. I have a few ideas (basically putting all the overhead in retire wait in the multiple waiter case), but I haven't gotten around to implement them.
You might as well use it to protect the refcount.
Eh, no. Refcounts have been protecting themselves for decades. :-)
The idea is that might be able to deduce the refcount from the shared state itself so you do not need an explicit counter.