{"id":5455,"date":"2018-06-15T19:58:40","date_gmt":"2018-06-15T19:58:40","guid":{"rendered":"https:\/\/www.modernescpp.com\/index.php\/the-end-of-the-detour-unified-futures\/"},"modified":"2023-06-26T11:49:28","modified_gmt":"2023-06-26T11:49:28","slug":"the-end-of-the-detour-unified-futures","status":"publish","type":"post","link":"https:\/\/www.modernescpp.com\/index.php\/the-end-of-the-detour-unified-futures\/","title":{"rendered":"The End of my Detour: Unified Futures"},"content":{"rendered":"

After the last post to executors,<\/a> I can finally write about the unified futures. I write in the post about the long past of the futures and end my detour from the C++ core guidelines.<\/p>\n

<\/p>\n

 \"technology<\/p>\n

The long past of promises and futures began in C++11.<\/p>\n

C++11: The standardized futures<\/h2>\n

Tasks in the form of promises and futures have an ambivalent reputation in C++11. Conversely, they are much easier to use than threads or condition variables; conversely, they have a significant deficiency. They cannot be composed. C++20\/23 may overcome this deficiency. I have written about tasks in the form of std::async<\/span>, std::packaged_task,<\/span> or std::promise<\/span> and std::future<\/span>. For the details: read my posts on tasks<\/a>. With C++20\/23, we may get extended futures.<\/p>\n<\/p>\n

Concurrency TS: The extended futures<\/h2>\n

Because of the issues of futures, the ISO\/IEC TS 19571:2016<\/a> added extensions to the futures. From the bird’s eye perspective, they support composition. An extended future becomes ready when its predecessor (then)<\/span> becomes ready, when_any<\/span> one of its predecessors becomes ready, or when_all <\/span>of its predecessors becomes ready. They are available in the namespace std::experimental. <\/span>In case you are curious, here are the details: std::future Extensions<\/span><\/a>.<\/p>\n

This was not the endpoint of a lengthy discussion. With the renaissance of the executors, the future of the futures changed.<\/p>\n

Unified Futures<\/h2>\n

The paper P0701r1: Back to the std2::future Part II <\/a>gives an excellent overview of the disadvantages of the existing and the extended futures.<\/p>\n

Disadvantages of the Existing Futures<\/h3>\n

future\/promise<\/span> Should Not Be Coupled to std::thread<\/span> Execution Agents<\/h4>\n

C++11 had only one executor: std::thread<\/span>. Consequently, futures and std::thread<\/span> were inseparable. This changed with C++17 and the parallel algorithms of the STL. This changes even more with the new executors you can use to configure the future. For example, the future may run in a separate thread, in a thread pool, or just sequentially.<\/p>\n

Where are .then<\/span> Continuations are Invoked?<\/h4>\n

Imagine you have a simple continuation, such as in the following example.<\/p>\n

\n
future f1 =<\/span> async([]{ return<\/span> 123<\/span>; });\r\nfuture f2 =<\/span> f1.then([](future f) {\r\n    return<\/span> to_string(f.get());\r\n});\r\n<\/pre>\n<\/div>\n
The question is: Where should the continuation run? There are a few possibilities today:<\/p>\n
    \n
  1. Consumer Side<\/strong>: The consumer execution agent always executes the continuation.<\/li>\n
  2. Producer Side<\/strong>: The producer execution agent always executes the continuation.<\/li>\n
  3. Inline_executor semantics:<\/strong> If the shared state is ready when the continuation is set, the consumer thread executes the continuation. If the shared state is not ready when the continuation is set, the producer thread executes the continuation.<\/li>\n
  4. thread_executor semantics<\/strong>: A new std::thread<\/span> executes the continuation.<\/li>\n<\/ol>\n
    In particular, the first two possibilities have a significant drawback: they block. In the first case, the consumer blocks until the producer is ready. In the second case, the producer blocks until the consumer is ready.<\/p>\n
    Here are a few nice use cases of executor propagation from the document P0701r184:<\/p>\n
    \n
    auto<\/span> i =<\/span> std::<\/span>async(thread_pool, f).then(g).then(h);\r\n\/\/ f, g and h are executed on thread_pool.<\/span>\r\n\r\nauto<\/span> i =<\/span> std::<\/span>async(thread_pool, f).then(g, gpu).then(h);\r\n\/\/ f is executed on thread_pool, g and h are executed on gpu.<\/span>\r\n\r\nauto<\/span> i =<\/span> std::<\/span>async(inline_executor, f).then(g).then(h);\r\n\/\/ h(g(f())) are invoked in the calling execution agent.<\/span>\r\n<\/pre>\n<\/div>\n
    Passing futures to .then<\/span> Continuations is Unwieldy<\/h4>\n
    Because the future is passed to the continuation and not its value, the syntax is quite complicated.
    First, the correct but verbose version.<\/p>\n
    \n
    std::<\/span>future f1 =<\/span> std::<\/span>async([]() { return<\/span> 123<\/span>; });\r\nstd::<\/span>future f2 =<\/span> f1.then([](std::<\/span>future f) {\r\n    return<\/span> std::<\/span>to_string(f.get());\r\n});\r\n<\/pre>\n<\/div>\n
     <\/p>\n
    Now, I assume that I can pass the value because to_string<\/span> is overloaded on std::future<\/span>.<\/p>\n
    \n
    std::<\/span>future f1 =<\/span> std::<\/span>async([]() { return<\/span> 123<\/span>; });\r\nstd::<\/span>future f2 =<\/span> f1.then(std::<\/span>to_string);\r\n<\/pre>\n<\/div>\n
    when_all<\/span> and when_any<\/span> Return Types are Unwieldy<\/h4>\n
    The post std::future Extensions<\/span><\/a> show the quite complicated usage of when_all<\/span> and when_any.<\/span><\/p>\n
    Conditional Blocking in futures Destructor Must Go<\/h4>\n
    Fire and forget futures look very promising but have significant drawbacks. A future created by std::async<\/span> waits on its destructor until its promise is done. What seems to be concurrent runs sequentially. According to document P0701r1, this is not acceptable and error-prone.<\/p>\n
    I describe the peculiar behavior of fire and forget futures in the post The Special Futures<\/a>.<\/p>\n
    Immediate Values and future Values Should Be Easily Composable<\/h4>\n
    In C++11, there is no convenient way to create a future. We have to start with a promise.<\/p>\n
    \n
    std::<\/span>promise<<\/span>std::<\/span>string><\/span> p;\r\nstd::<\/span>future<<\/span>std::<\/span>string><\/span> fut =<\/span> p.get_future();\r\np.set_value(\"hello\"<\/span>);\r\n<\/pre>\n<\/div>\n
     <\/p>\n
    This may change with the function std::make_ready_future<\/span> from the concurrency TS v1.<\/p>\n
    \n
    std::<\/span>future<<\/span>std::<\/span>string><\/span> fut =<\/span> make_ready_future(\"hello\"<\/span>);\r\n<\/pre>\n<\/div>\n
     <\/p>\n
    Using future and non-future arguments would make our job even more comfortable.<\/p>\n
     <\/p>\n
    \n
    bool<\/span> f<\/span>(std::<\/span>string, double<\/span>, int<\/span>);\r\n\r\nstd::<\/span>future<<\/span>std::<\/span>string><\/span> a =<\/span> \/* ... *\/<\/span>;\r\nstd::<\/span>future<<\/span>int<\/span>><\/span> c =<\/span> \/* ... *\/<\/span>;\r\n\r\nstd::<\/span>future<<\/span>bool<\/span>><\/span> d1 =<\/span> when_all(a, make_ready_future(3.14<\/span>), c).then(f);\r\n\/\/ f(a.get(), 3.14, c.get())<\/span>\r\n\r\nstd::<\/span>future<<\/span>bool<\/span>><\/span> d2 =<\/span> when_all(a, 3.14<\/span>, c).then(f);\r\n\/\/ f(a.get(), 3.14, c.get())<\/span>\r\n<\/pre>\n<\/div>\n
     <\/p>\n
    Neither the syntactic form d1<\/span> nor the syntactic form d2<\/span> is possible with the concurrency TS.<\/p>\n
    Five New Concepts<\/h3>\n
    There are five new concepts for futures and promises in Proposal 1054R085<\/a> to unified futures.<\/p>\n