Let's see if I've captured everything: - we want to get a value from (likely) another THREAD, and WAIT if it is not yet ready UNTIL it is ready, (whatever THREAD WAIT UNTIL mean) - a future (boost:: or std:: or hpx:: etc) is a (high-level!) wrapping of that concept - to be inter-operable we need the lower level concepts (in ALL-CAPS) exposed THREAD: we actually don't need to completely define what "another" THREAD is, we only need a partial definition of our OWN THREAD. ie the *thread of execution* of the current code, because any code (that we assume at some point runs) runs in some "thread of execution" - whether user mode thread, kernel thread, HPX, whatever... What we really need is access to the _controller_ of that thread of execution - ie typically the scheduler, but not a full scheduler interface. In recent C++ proposals this has been called the "execution agent", although I've been pushing for EXECUTION CONTEXT - the C++ object/interface that controls the context of the execution of the current set of instructions. WAIT: The running code needs to be able to get at its EXECUTION CONTEXT in order to be able to ask it WAIT. For a given EXECUTION CONTEXT, WAIT means stop "running" - stop using CPU, etc. No further PROGRESS (which turns out to be a hard term to define, but the committee is working on that) UNTIL: Some *other* EXECUTION CONTEXT needs to be able to tell the aforementioned EXECUTION CONTEXT to RESUME. Note that I've left off the actual value inside the future, and the "waitable" object (kernel or otherwise). The value is orthogonal - the value is just a memory location (unless we abstract that away!) and can be set via atomic operations or whatever. Once the value is set, you then call RESUME on the execution agent. From a value point-of-view, what you want is just an ObservableValue. ie when value is changed, call this callable (function, lambda, whatever). Given an ObservableValue, and an ExecutionAgent you can build a promise. Tony