Forgive me if this is dumb I haven't looked at the implementation of a future/promise solution before and I was curious. It seems the basic strategy is to have a member variant called value_storage in both the promise and the future. Let me see if I can enumerate the flows: - If you set_value on a promise twice you get an already_set error. - If you set_value on a promise that noone has gotten the future of you set the storage of the promise to the value - If you set_value on a promise that someone has gotten the future of you set the storage of the future to the value and detach the promise from the future - If no one ever gets the future and the value is set then the value gets destroyed in the promise's storage when the promise is destroyed - If someone gets the future before the value is set then a future is constructed and the promise's storage stores a pointer to the future - If someone gets the future then gets it again while the first future still exists it throws future_already_retrieved - If someone gets the future then destroys the future then gets the future again it is now safe to call get_future again on the promise so long as the value was never set (This seems rather complicated, is it necessary?) - If someone sets the promise value then gets the future this is the fast path no lock is ever taken, the promise is left detached with empty storage and the value has been moved to the future's storage Is this about right? I'm not sure that _need_locks being changed inside of get_future is always going to be visible other threads. The documentation says it will be thread safe after you have called get_future but I don't see anything that necessarily creates a happens-before relationship between other threads reading _needs_locks. I am not an expert though.