Concerning std::futures and promises, my thought is wrapping an immutable state in a task, nither future or promise, but with elements of both. Creating a mutex from an asm lock cmpxchg wrapped in c ( available most platforms ) to a shared_ptr gives you a copyable mutex. Not that it matters, but if the state manager ensures a swap every time the arguments are updated, and the state has a ref count destructor, a value storage, function/lambda/member func/functor storage, the effect is an immutable state. once the args are set nothing can change but the execute function or function brackets, a flag in the state ensures that the func will only execute once ( all flags set by single asm instruction xchg, wrapped in c ). this task , or promise if you like, is now copyable, and doesn't require an allocator as the internal state is set by setting the arguments and the state ptr and can be created then. Every time the task/ promise gets copied the shell only exists to point to the state. Having a generic function that wraps any func call in a std::function<void()> using a lambda , works nicely for a basic way to fill a queue generically. In the end you only have two exposed objects. A task and a scheduler. No mutexes, futures, promises, or any locking mechanisms of any kind. The task implementation I'm speaking of also accepts lambdas, and can reset there arguments. The thought is creating the shell (task , promise, whatever) once. Then setting the arguments many times. Each time it would internally create a new state, the user still has to take care of the memory, less the ref count get to zero, but a simple vector does nicely. Since it is all wrapped in the copyable task/promise, it is transparent to the user. So... task(any function in with or without args), task.set_args, scheduler.queTask, and go. The scheduler is just a thread grouping dictated by the user or by the hardware concurrency as a default. The result can be retrieved directly through the task or it can create a future as well or fill an existing one with the original future ref in the state. Don't really need it but... if it must be future/promise. Biggest problem i had was dealing with the lambda and functor case intuitively and cross platform. Functions and member functions were a snap.