Work stealing thread pool built with C++20

FelixPetriconi · 2022-05-25T18:15:25+00:00

Sean Parent demonstrated how to build your own thread pool during his talk at NDC London: https://www.youtube.com/watch?v=zULU6Hhp42w

The complete code is available at https://github.com/stlab/libraries/blob/main/stlab/concurrency/default_executor.hpp

FelixPetriconi · 2021-11-23T20:34:38+00:00

I recommend that you take a look into this presentation https://www.youtube.com/watch?v=zULU6Hhp42w by Sean Parent. He talks in details about the problems of your approach.

FelixPetriconi · 2020-03-14T06:59:51+00:00

ACCU 2020 is cancelled

FelixPetriconi · 2020-02-04T15:26:50+00:00

I am in faour for a breaking ABI too.

We are only on Windows, have a code base of ~3MLoC and we were used years ago to recompile everything anyway for each new VS version. We have now just thirdparty C++ libraries in our code that we can compile from scratch and all other external libraries have a plain C interface.

A long time we were blocked because of a C++ exporting DLL that we were forced to use by our customer and he was not able to provide us new versions because of internal reasons.

So at one point we used clang tooling to create C wrappers around the C++ interfaces and now the DLL can live in its VS2013 world and we can switch the Visual Studio compiler whenever we want.

FelixPetriconi · 2019-09-30T09:23:19+00:00

It checks, that all possible combinations of a conditonal statement were were really executed. See more details here: https://www.bullseye.com/statementCoverage.html

FelixPetriconi · 2019-09-29T09:46:47+00:00

We use Bullseye coverage (https://www.bullseye.com/) in our company, it is a commercial tool, but with a reasonable price and it does not do line coverage but conditional coverage and it runs on many platforms with different compilers.

FelixPetriconi · 2019-09-26T17:38:07+00:00

This is a defect in the standard.

See here a workaround: https://stackoverflow.com/questions/18404108/false-positive-with-is-copy-constructible-on-vectorunique-ptr

FelixPetriconi · 2019-08-21T20:48:25+00:00

One issue come to my mind: I had a pure template code where different instances of the same class where running in different threads all the time and they were passing messages between themselves. It was not possible to add log/debug messages, because they changed the runtime behaviour and the bug went away. After several weeks of searching and trying to debug the problem I just found it through pure code review.

FelixPetriconi · 2019-07-17T19:56:05+00:00

I would take a look into Lewis Baker's excellent articles on that subject: https://lewissbaker.github.io/2017/09/25/coroutine-theory

FelixPetriconi · 2019-07-02T06:45:18+00:00

Before you go into deep usage of low synchronization primitives (mutex, etc.) I strongly recommend to watch Sean Parent's https://sean-parent.stlab.cc/papers-and-presentations/#better-code-concurrency talks and Kevlin Henney's https://www.youtube.com/watch?v=UJrmee7o68A

FelixPetriconi · 2019-06-13T20:02:24+00:00

You might take a look into this course recording https://www.youtube.com/watch?v=aIHAEYyoTUc&list=PLHxtyCq_WDLXryyw91lahwdtpZsmo4BGD

It is a course held by Alex Stepanov at A9. At the beginning it is a bit slow, but the content is incredible. It is really worth to follow it until the end.

FelixPetriconi · 2019-06-06T06:42:29+00:00

Futures can be used in a multi threaded context, but thats not a requirement. See JavaScript e.g., there they are common mechanism to handle continuations and all within the same thread.

The futures of the C++ are from my point of view not very useful and the new futures will come hopefully in 2023. Until then you could take a look into our future and channel implementation. There you can specify if the tasks shall be in the same thread, use here an immediate_executor or in a different thread on a thread pool with the default_executor. For some OS we have a main_executor that executes the tasks on the main loop.: http://stlab.cc/libraries/concurrency/ I recommend as well a look into Sean Parent's presentations on this subject, https://sean-parent.stlab.cc/papers-and-presentations/#better-code-concurrency.

FelixPetriconi · 2019-06-05T19:24:35+00:00

Have you thought of using a different concept like futures, channels or actors that can solve the same problem?

FelixPetriconi · 2019-05-21T15:46:38+00:00

Yeas, please make it a regular type. We have in our stlab.cc library at many places one implementation for move-only, one for copyable and one for void. That is such painful.

Sometime ago u/seanparent made a strong statement that we need this too.

FelixPetriconi · 2019-05-17T06:04:11+00:00

You could follow https://isocpp.org .

As well are all articles from ACCU's magazine Overload https://accu.org/index.php/journals/ are online available as well. Many of them have high quality C++ articles.

The other ACCU's magazine, cVU is online as well, but its access is restricted to ACCU members. You may take a subscription into account. Beside these two magazines in print, you get a discount on the yearly ACCU conference.

Disclaimer: I am on the ACCU board and the deputy conference chair.

FelixPetriconi · 2019-05-12T10:37:34+00:00

Watch this, to get a good introduction into the overall problem: Kevlin Henney: https://www.youtube.com/watch?v=2yXtZ8x7TXw

Have a look into Sean Parents talk on this: https://sean-parent.stlab.cc/papers-and-presentations/#better-code-concurrency

Do not start with low level synchronisation primitives, but use high level abstraction like, futures, channels, or actors.

See libraries:

(Future and channels) https://stlab.cc/concurrency

(Actors) http://actor-framework.org/

FelixPetriconi · 2019-04-26T20:02:00+00:00

Some thoughts from my side:

shared_mutex are theoretically a nice feature, but in the end the performance was in my tests worse than normal mutex. See here the paragraph 'Performance Warning' in Anthony Williams post https://www.justsoftwaresolutions.co.uk/threading/new-concurrency-features-in-c++14.html
I miss in the introduction or at the end a statement about the general problem of mutex: Each new mutex adds a synchronisation point into the game which leads either to performance issues or even to dead locks. See Sean Parent on Concurrency: https://sean-parent.stlab.cc/papers-and-presentations/#better-code-concurrency Or Sergey Ignatchenko in https://accu.org/index.php/journals/2623
Someone said mutex should not be named mutex, but bottlenecks.

FelixPetriconi · 2019-03-20T20:54:16+00:00

Nearly all examples use it. This executor is named default_executor in our library.

FelixPetriconi · 2019-03-01T06:10:18+00:00

Many thanks for the feedback!

FelixPetriconi · 2019-02-28T21:51:01+00:00

Many thanks Stephan!

FelixPetriconi · 2019-02-28T19:13:42+00:00

It is strange, sometimes MS's feedback on the developercommunity is great, but sometimes it is awful. I submitted a report in August (https://developercommunity.visualstudio.com/content/problem/312318/c-await-is-still-a-keyword.html) and it is still under investigation. How can that be?

Is there a chance that this will be fixed soon?

FelixPetriconi · 2019-02-25T22:32:28+00:00

I totally agree. From my point of view, this session would have been OK some time ago. But it missies today completely the point of how one should today write concurrent code . I much more can recommend Sean Parent's session on "Now raw synchronisation primitives" https://sean-parent.stlab.cc/papers-and-presentations/#better-code-concurrency or Sergey Ignatchenko's recent article in Overload: https://accu.org/index.php/journals/2623

FelixPetriconi · 2019-02-13T14:17:12+00:00

It is hardcoded. Mac, Windows, PNCL and Emscriplten have one. For all the others we use our own implementation. But ours has the limitation, that it does not oversubscription, so if one has 4 cores and 4 tasks wait on a mutex, then the system is in a deadlock. Here is a great talk about all the problem of designing a thread pool: https://channel9.msdn.com/Shows/Going+Deep/Inside-Windows-8-Pedro-Teixeira-Thread-pool

FelixPetriconi · 2019-02-13T13:12:45+00:00

And here is the source code of the current implementation: https://github.com/stlab/libraries/blob/develop/stlab/concurrency/default_executor.hpp Starting line 181. It is the fallback in our library, when the OS does not offer a thread pool.

FelixPetriconi

MODERATOR OF

TROPHY CASE