Learn to Code via Tutorials on Repl.it!

← Back to all posts
How and why to use threading in C++

Have you heard of multithreading and just wish you could make your programs faster?
Well... unfortunately just using threads is not enough, you have to use them correctly.
More threads can make things faster, but too many threads or using them on the wrong things can make it slower!

If you are building a house you undoubtedly have a lot of work to do, but if you have a team you can get it done faster.
If you do it all yourself without any help it will take forever, and it will take just as long or longer if all of you are working on the same thing.
So if everyone gets a different task then multiple things can be done at the same time and by the time they are all finished the house is ready to be put together.

Now this isn't a really great example as I couldn't think of a very good example of a program that benefits from threading off the top of my head but the idea is there and if you made it into a game or something with some more complicated logic like physics it would really make a difference.

I also couldn't find a very significant project to demonstrate thread safety reliably but I'll explain it.
To make that house you need wood or whatever you are making it out of right?
Well if everyone needs a piece of wood and two of them want the same piece what then?
Remember that you have a builder team of idiots so instead of just getting a different piece they both work on the same piece! Each one had a different job so the resulting plank came out an unrecognizable mess!
But if you tell them to take turns, everything works how it should. The second person has to wait for the first one to get their piece.

Basically, the whole benefit of threading is that you can do multiple things at the same time, like web requests for example.
If you don't have anything else to do while your threads are working, you might be better off with just a single thread.


are you for hire to game dev?


@HeadSucksAtLife I can't really do any art things but I'd make a game if it was a good idea and actually had animations and stuff already done.


@HeadSucksAtLife Doesn't look like a team that will get far. I can point out every detail that's wrong with it but that's probably not what anyone wants.


Yk RayhanADev right? hes on it @CSharpIsGud


@HeadSucksAtLife Yeah, along with basically every single person that's asked.


? Wdym @CSharpIsGud


@HeadSucksAtLife You haven't declined a single person


Because they all have sent real good examples and some of those comments are from people that were later kicked out of the team. @CSharpIsGud


@HeadSucksAtLife bruh one dude literally had projects were just this


@HeadSucksAtLife And oh yeah that music bot is forked from https://github.com/eritislami/evobot and I highly doubt that's his github account.

That's like 2/4.


Yeah and they arent in the team... @CSharpIsGud


@HeadSucksAtLife It's pretty doomed to be a canvas game. So it would take a really good idea to get me to touch it.


We don't make games for ourselves, we make them for people who order them. and you can get some of the revenue @CSharpIsGud


@HeadSucksAtLife Well judging by the remaining that 'applied' they never included any experience or knowledge of game engines.


We don't necessarily use game engines. @CSharpIsGud


@HeadSucksAtLife Then you won't necessarily make good games, people wouldn't order, let alone pay for a canvas game.

And I know you are going to try to say you don't need one to make a good game.
You technically don't, but almost no one that makes decent games does.
Keep in mind that almost applies to very specific people.
You never asked for anything specific, you just asked for programmers, and most of who you got were website devs.
It is a very small chance that any of them know things like advanced vector math they would need to do something like an advanced game.
And lastly, the above is just a fraction of the work. No game engine means you have to do rendering and collision checks yourself too. (P.S collision checks get much much harder when rectangles aren't the only thing in said game.)

So, you can either just use a game engine and make a game normally.
Or just make them without one and stop expecting that they will make 'revenue'


@HeadSucksAtLife Canvas games suck, period. I've seen Java programs ported to a canvas, and they weren't fun. I've worked on teams and developed canvas games, they were missing so much. The only proper games on the web use WebGL.
An example, in action: https://get.webgl.org.

And any good games made in it use game engines.

The last time I dared to make a multi-threaded canvas, it didn't even work.

Also, JavaScript is a very poor language to develop a game in, easily one of the worst.


While making threads isn't too expensive, locking a mutex is.


@liltaco Making threads take usually 1000/2000 > cycles.

Locking a mutex on its own isn't very expensive, but if the mutex is already locked the mutex has to spend time with syscalls when another thread starts waiting on it, which slows threads down by a lot.


More threads can make things faster, but too many threads or using them on the wrong things can make it slower!

More threads won't slow stuff down? More atomic operations will, right?
Unless you spawn over 50 threads that consume large amounts of memory and are CPU intensive, the threads themselves won't slow anything down.

Besides that, this really should've used std::cin.get() instead of std::cin operator>>.


@xxpertHacker The whole point of concurrency is to do multiple things at once, if you make a whole bunch of threads to do one thing it can be slower, or if you make a bunch of threads for a task only to turn around and wait for them all to complete it can definitely be slower than if you had just used a single thread.
I have a fibonacci program in C++ that I used a fast algorithm for, I tried to add threading to it and generate different parts of the sequence at the same time but it made it slower either because of the threads or that I had to wait for them to finish.



@CSharpIsGud Ah yes, I seem to have forgotten that your house building examples were given to emphasize that threads aren't meant to all do the same thing.
I forgot that too soon.

But I still feel like that ties more into the last part of your sentence, not the beginning, which is what I am arguing against.

...or using them on the wrong things can make it slower!

Whereas just using more threads won't make anything slower, it's the misuse of threads that can slow you down.

Also, do you have any estimate on how expensive it is to spawn a thread? If it's an expensive operation, then simply spawning the threads could waste more time than it could save.

I was recently thinking about making a multi-threaded compiler.
The program that would, from the very beginning, be split into four separate threads: the lexer, the parser, the optimizer, and the compiler (maybe the compiler and optimizer would be the same thing).
They would work in sequence, yet they would each work independently. The parser would have to wait for the lexer to lex the next token, yet the opposite is not true, the lexer would not have to wait for the parser to parse the token.
I am thinking of streaming the code all the way through, instead of just trying to do everything all at once.

In your opinion, would this be a bad idea or not? Do you believe it would operate slower than the single-threaded version? Do you have any suggestions as to how it should be organized overall?


@xxpertHacker Creating a thread can take like a thousand or so cpu cycles.

Even if you create it beforehand you still have the inter-core latency or whatever, so if you have small tasks that don't take much work at all to do you are better off not using threads for it.

A lexer doesn't have to wait on a parser anyway, it would still be parsed at the same speed because everything has to wait for the previous stages to do its tasks, most of the parsers thread time would be idling.



Creating a thread can take like a thousand or so cpu cycles.

Ooh, that is bad. I'll keep that in mind when spawning threads from now on.

Even if you create it beforehand you still have the inter-core latency or whatever...

I have not heard this mentioned anywhere, not even the term; I'll have to go research it later.

A lexer doesn't have to wait on a parser anyway, it would still be parsed at the same speed because everything has to wait for the previous stages to do its tasks, most of the parsers thread time would be idling.

So, you're suggesting that I cannot attempt to stream the process? As it reads a token, I cannot attempt to send it to the parser immediately, but instead must wait for everything to finish? Are there other setups that could allow this?


@xxpertHacker You can stream it, but it will work basically the same. The parser won't be able to do anything until it has enough tokens from the lexer, so it will be idling most of the time. And idling threads kind of nullifies the whole point of using multiple threads.

As for thread creation, you can make threads in advance.
C# has its ThreadPool class which creates N threads that are always ready to be used.


@CSharpIsGud I was going to spawn the threads at the start of the program, what is the difference between using a thread pool? Are they ready prior to program start?


@xxpertHacker Spawning them at the beginning of the program should work just as well.


Alright. You've got some valid points here. Keep it up!