I didn’t write on this blog for years now. Here is what I am doing right now. I am a C++ software engineer in Diagdev, a hematology-related company based in the south of France near Montpellier. I also developed a little library: Little Type Library. The goal of this library is to add range and concept like to C++17. It also brings other functional features with the pipe notation or the >> notation. We will see how to create a future using coroutine
What is a coroutine?
A coroutine, even if the name is complicated, is a simple thing. Functions begin, do things, and end. A coroutine is a kind of generalization over functions and they can be stopped and resumed in the same, or better, in another thread.
A coroutine can be stopped either at the beginning, during the processing, or at the end.
What is the problem with conventionnal future?
Let’s say we have this code.
C++
1
2
3
4
5
6
7
8
9
10
#include <future>
intmain(){
auto performSomething=[]{};
auto future=std::async(performSomething);
doSomething();
future.wait();
}
If performSomething and doSomething last the same duration, there is no issue, but if performSomething lasts longer, the future.wait() will make the main thread stalls during some instant, and so, you lose performance. If the performSomething lasts longer, there is a thread that does not do anything and so, we lose performance.
Monadic expression is a way to solve it. The idea is to give the future one callback that will be automatically called when the asynchronous function ends. If you want to know more about this, I wrote an article a few years ago.
How coroutines can solve the problem
Actually, my solution using coroutine is like monadic expression. However, instead of giving a callback, you write the function normally.
Here is the code we want to achieve.
C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
intsquare(intx){
returnx*x;
}
taskf(){
auto squared6=co_await async(square,6);
std::cout<<squared6<<std::endl;
}
intmain(){
std::jthread thread;
::thread=&thread;
f();
doSomethingHeavy();
return0;
}
I don’t manage in a clean way my threads to be simpler. I used jthread instead of thread for its auto-join. This code is simple. The main function call f which is a coroutine. The coroutine f calls async with square and 6 as arguments. Async returns an awaitable awaited in f. The await launch square in another thread. f saves its state and returns to main. Once the thread finishes computing square, it resumes the coroutine f, and prints the squared value.
Yes you read it properly, the std::cout << squared6 << std::endl is executed in the same thread as square.
So, let’s create a future using coroutine !
Async coroutine
The job of the async coroutine is to return a future and launch the given function when we co_await the future. So here is the code :
Since we use the co_return keyword, async is a coroutine. We don’t want to execute f directly, so we need to stop the coroutine at the beginning. We also need to stop at the end to avoid use after free. Since the coroutine is stopped before its beginning, we need to save the result of the function. To finish, the future has the handle of the coroutine to be able to resume it.
We see that the future has an co_await operator. This operator needs an awaitable object. An awaitable has 3 methods.
await_ready: to know if we must stop the coroutine or not
await_suspend: Called when we suspend the coroutine, it is here we will launch the other thread.
await_resume: To return the result to the called of co_await.
For our future, the awaitable will look like that:
C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
structAwaitableFuture{
future&m_future;
boolawait_ready()constnoexcept{returnfalse;}
voidawait_suspend(std::coroutine_handle<>handle){
*thread=std::jthread([this,handle]{
m_future.coro.resume();
handle.resume();
});
}
Tawait_resume(){
returnm_future.coro.promise().value;
}
};
Why do we need to call resume twice? Let’s remind the usage of the future :
C++
1
2
3
4
5
taskf(){
auto squared6=co_await async(square,6);
std::cout<<squared6<<std::endl;
}
f is a coroutine, but async also! The future coroutine is to resume the async one, and the await_suspend one is to resume f. The order is important, else, you will not compute the value before resuming f.
Since f is a coroutine, here is the simple code for the task :
Here is a full code with an online compiler if you want to try it.
Conclusion
I hope you understand this article well, and if you have some questions, don’t hesitate to ask :). For the future, I could write an article about how to create a when_all using coroutines, or how to use a thread pool with coroutines.
Hi, there is a long time I have not written anything, sorry for that! I planned to write several articles during these few next weeks. This article will deal with multithreading.
Introduction
In a lot of articles, we can read that multithreading is not easy, and other things like that. In this article, we will learn how to write multi-threaded application in a simple and a fun way.
The idea will be to write something like that
// Launch the chain of function in an asynchronous way
test.execute(asynchronous_scheduler{});
// Do some work very expensive
auto result=test.waitAndGet();
auto first=std::get<0>(result);// tuple(8, 25)
auto second=std::get<1>(result);// -17
std::cout<<second<<std::endl;
return0;
}
If we write a little scheme, it gives us that :
Multithreading in action
Obviously, when the function f3 starts, functions f1 and f2 must have complete. The same thing happens for the getResult. It must wait for f3, f4, f5 to complete.
Does it really exist?
Actually, it does, and it will even be in the standard in C++20. However, the feature from the C++20 suffers from different problems that are explained in the Vittorio Romeo article. Actually, this article could be a continuation of the series of articles from Vittorio.
Multithreading with Monadic Expression: Implementation
I hope you really love read ununderstandable C++ code because the code is full of template and metaprogramming. I recommend to have some basis in really modern C++ or read the series from Vittorio I was talking before. We are going to see a lot of things both in multithreading and metaprogramming
Why do we need a continuation of the series from Vittorio?
Firstly, the code provided by Vittorio does not work on Visual Studio, and I really want to have my codes work on all compilers and all operating systems. Second, in its article, he only provides a version using a function waitAndGet that prevents us to insert code into the main thread in an easy way.
The third issue is that the group of functions returns a std::tuple
For example, you must have to write something like that
But, in reality, some people will prefer the first version, other will prefer the second version. What will happen if a function does not return any arguments? According to me, the second version is more natural.
Forwarding
Because we are going to use a lot of metaprogramming, we may need to perfect forward some arguments. Here are two macro that defines a perfect forwarding. There is one macro for a normal variable and another one for auto. I was not able to use the same one for both cases because sometimes, use the form ::std::forward<decltype(variable)>(variable); is too difficult for Visual Studio, that is why I provide these both declarations.
A latch is useful when you want to know if a job is finished or not. Let’s say you have two thread, which one of them is waiting the result coming from the second one. The first one need to wait the second to finish.
Latch
The following code shows how to implement a simple “bool_latch”
bool_latch.h
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
#pragma once
#include <mutex>
#include <condition_variable>
classbool_latch{
public:
/**
* Function to call when the job is finished
*/
voidjob_done(){
{
std::scoped_lock<std::mutex>lock(mMutex);
mDone=true;
}
mConditionVariable.notify_one();
}
/**
* Function to call when you want to wait for the job to be done
The code is based on condition_variable, mutex, and a boolean variable
The return type
Each function may return one value. However, what returns a group of functions? The better choice is to return a std::tuple. Thus, if you have three functions that return an int at the same level (running in 3 parallels threads), the result will be a std::tuple<int, int, int>.
Functions that return void.
The simple way for this case is to create an empty type that we will name nothing. Its declaration is straightforward.
1
structnothing{};
The function, instead to return nothing, must return the type nothing.
Let’s say you have three functions, f1, f2, f3. f1 and f3 return an int and f2 returns nothing. You will get a std::tuple<int, nothing, int>
How to return nothing instead of void? This function explains that in a straightforward way!
callThatReturnsNothingInsteadOfVoid
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
namespacedetail{
template<typenameF,typename...Args>
/**
This function returns f(args...) when decltype(f(args...)) is not void. Returns nothing{} else.
@param f - The function
@param args... - Arguments to give to the function
@result - returns f(args...) if possible, or nothing{} else.
Okay, now say you have a std::tuple<int, double, std::string> and, you want to give it to one function with a prototype like returnType function(int, double, std::string).
One way to do that is to use the function apply.
Here there is no problem, but assume that there is a nothing in your tuple like std::tuple<int, nothing, int>.
When you will apply this tuple to the function, you will also pass the nothing.
To avoid such problem, you must filter all the arguments and store the arguments inside a lambda function.
This part will be the most difficult part of the article. We will see how the architecture work. It is an architecture with nodes. We will see three kinds of nodes. The root node that is the beginning of the chain of functions, the when_all node that can own one or several functions which will run in parallel and one node result_getter that represents the end of the chain of functions.
Overview
Overview of multithreading
As you may have noticed, there is no type erasure. The type owned by the caller is the result_getter. However, the result_getter, when it executes all the functions, it must return to the root. And to do that, it must go through the when_all.
Now go to explain whole the code!
root
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
#pragma once
#include <tuple>
#include "fwd.h"
namespacedetail{
classroot{
template<typename Parent,typename...F>
friend classwhen_all;
// A node produce nothing
using output_type=std::tuple<>;
private:
// Once you are at the root, you can call the execute function
There is nothing difficult here. The when_all is a friend. There are two functions, the first one is called by the children and its purpose it’s only to reach the top. After, you execute the child functions through the scheduler.
This is the most difficult part.
However, everything is not difficult. There are two things that are difficult. The output_type and the execute function.
1
2
using input_type=typename Parent::output_type;
using output_type=std::tuple<decltype(callWithoutNothingAsArgument(std::declval<Fs&>(),std::declval<input_type>()))...>;
The input_type is straightforward, we take the output from the parent. The output_type is a bit tricky. The idea is to call all the function, and for each of them, add the result to a tuple.
There are several things to think about.
The exec lambda is the function that will be executed in a parallel thread. We store the value inside the good position of the tuple. If all functions have finished, we call the execute function for the directChild. This condition is checked by mLeft.
The executeOneFunction lambda is the function that computes if the function must be launched through the scheduler or not. (If there is only one function, there is no need to launch it through the scheduler because the root already did that).
The enumerate_args execute the function with each arguments, and give the index as an argument as well.
using type=typename detail::tuple_without_nothing_impl<std::tuple<>,Args...>::type;
};
template<typename Tuple>
using tuple_without_nothing_t=typename tuple_without_nothing<Tuple>::type;
template<typenameTuple>
structepurated_tuple{
using type=std::conditional_t<
std::tuple_size_v<Tuple>==1,
std::tuple_element_t<0,Tuple>,
tuple_without_nothing_t<Tuple>
>;
};
template<>
structepurated_tuple<std::tuple<>>{
using type=std::tuple<>;
};
template<typename Tuple>
using epurated_tuple_without_nothing_t=typename epurated_tuple<tuple_without_nothing_t<Tuple>>::type;
The idea is to remove the nothings from the tuple, and if the tuple owns only one type, the tuple is removed and we get only the type.
Conclusion
In this article, you learned how to write safe and easy to read multi-threaded functions. There is still a lot of things to do, but it is really usable and easy to use. And if someone else has to read your code, he should be able to do so.
If you want to test it online, you can go on wandbox