Re: [boost] Lightweight futures (was: Re: Final lightweight monad, next gen futures and upcoming AFIO review

Subject: Re: [boost] Lightweight futures (was: Re: Final lightweight monad, next gen futures and upcoming AFIO review
From: Michael Marcin (mike.marcin_at_[hidden])
Date: 2015-06-30 23:37:29

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.