What exactly is threading? What to learn next?

Hi, LeafyCircuits here!

I was wondering what threading is in C++. I've done some research and I guess the idea is to have separate process that run parallel to each other in a program. I'm not sure if I'm hitting in the ballpark with that description, so I was wondering if someone could explain threading properly, or at least point me to a good tutorial.

I also realize that people have asked this question several times on here. But searching the forums here wasn't very successful for me. If you know of a thread though, you can point me to it too. :)

I was also wondering if you guys think I should tackle this area of C++. I am a 15 year old, self-taught programmer and I've been programming for 1 and 1/2 years now. My main source of knowledge is a book called "C++ for Dummies, 2nd edition" (2006). I got started with C++ with that book, but being published in 2006, it was on C++03, so I started browsing the internet for the C++11 techniques and libraries. I'm fairly decent now in C++ and currently I'm learning about the <chrono> library, and I've been using PDCurses a lot lately. However, I still need a lot of practice before I feel like I can call myself "good" at C++. I want to start moving into WinAPI and Boost sometime, or just basic graphical/auditory programming (getting tired of that old terminal :3).

With that in mind, I would like to know if you guys think threading is a probable thing to get into. And while were on the subject of learning: I need some guidance....

Right now, I feel like I don't know what to get into as far as C++ goes. I'm kind of doing bits and pieces of certain subjects, like polymorphism, making templates (and making them well), multiple inheritance, understanding standard IO and file IO, binary files, hashes, and STL containers to name a few. But all that knowledge is too much to tackle all at once, and my experimental programs are suffering because of it. I often run into a bug that I can't fix, and I have this feeling that it is caused by my lack of practice and knowledge in that area. So when I go and study that particular area for a bit, it mentions something else that I'm interested in learning that relates to that subject, and I'm like "oooh, I wonder how that works too", and then my mind flies all over the place.

What I want to know then, is your experience: how did you start learning C++? What was your learning curve? What subjects did you learn first/last? Do you think that you should learn x before you learn y? What did you suggest to other people that helped them understand C++ better?

Replies are most welcome. Thanks for reading :)
Also, I realize how Ironic it is that this thread is right next to another thread asking a similar question. That won't be for long though....
Last edited on
Threading, aka Multithreading, isn't unique to C++ - it's in every operating system and nearly all languages support it to some degree.

You have a good description, but you may not be aware what you're getting into. Multithreading is like performing a surgery in the dark on a patient that changes physiology every five minutes. It's very tricky to get right and you may never even know you got it wrong.
threading is execution a function in the processor with a time and a speed that the processor may execute
when a thread is executed, you can't use that part of the processor until the thread has been unlocked
so, if you dont unlock the thread after execution, it will be locked and your processor cant be used before you restart your computer
compilers support multi threading like MinGW on windows, GCC on linux, and some others
Well, multithreading sounds like something I should tackle much later on. But I am still curious....

So, with multithreading, I can have different code run at the same, essentially. That sounds like it could speed up execution time, or am I wrong? Also, what would be the purpose for multithreading? Can anyone name a situation where multithreading is advantageous? I guess one situation is if your a game programmer. I can imagine that programming an environment would be hard to do if code was executed from start to finish. I imagine there would be many things that have to happen at the same time, like game ticks, rendering, audio cues, etc.
I assume you're familiar with Minecraft?

While the main game thread is running and letting you play the game and look around, other threads are running at the same time generating or loading new chunks and then rendering the chunks after they have been generated/loaded. Also there are threads for unloading the chunks and saving them.

The classic chunk error issue is caused by programming mistakes with the multithreading. Consider walking toward chunks and then changing your mind, walking back, and then changing your mind again and walking toward the chunks. This causes a thread to spawn to load the chunks, then a thread to spawn to unload the chunks, and then it doesn't spawn a new thread to load the chunks because there is already one. unfortunately due to a coding mistake (which is difficult to resolve) the chunks may be loaded and then instantly unloaded, and then the game doesn't try to load them anymore.
Last edited on
Yes, I am familiar with Minecraft. So I guess this is why you likened multithreading to that amazing surgery simile.
That sounds like it could speed up execution time, or am I wrong?
That's an illusion. The processor doesn't work faster thru this. In opposite: multithreading done badly might very well slows your program down due to synchronization problems
Last edited on
Only some parts of algorithms can be evaluated simultaneously:

Synchronization and/or passing information between computing elements is additional overhead work compared to sequential single-thread execution. It consumes cycles, even if it would be parallel.

Different threads can do different operations, or they can all do the same calculation but for different data.

For some computational problems, with sufficient hardware, the required wall-clock time can shrink a bit. However, just like in graphics, "faster" is not as fun as "more" is.

Hardware has been moving towards parallel for quite a while now. Learning some of it is clearly useful.
Last edited on
closed account (o1vk4iN6)
Multi-treading isn't *that* difficult, it mostly depends on what you are doing with it and in some cases it does get complex and hazardous to errors. That minecraft error isn't cause multithreading it's a bad choice by the designer to not load all chunks in a radius assuming he can predict where the user wants to go. There were a lot of things wrong with Minecraft, it seems more like it was a learning experience for whoever was making it. I think they still use TCP for all their netcode (not to mention the desyncing of players position).
The bugs in Minecraft seem like they were a challenge to even create in the first place...some of the bugs I just have absolutely no idea how they could possibly exist...
Well, thanks for all the feedback guys. You have answered my question about threading, but I'll leave this thread (no pun intended) open anyways for further discussions.

In particular....

I also was wondering what concept I should tackle next in C++. As I've stated up there, I don't really know where to turn to. My focus is more of a game programmer, which is why I'm really interested in <chrono> right now for clocks and timers. Actually, specifically about <chrono> and game programming, how does one define game ticks? Going back to Minecraft, since we were on the subject, there are game ticks which are defined to be 1/20 of a second. Through these game ticks (mostly), the game environment can have updates about particular things (such as crops growing, you moving, etc.), and then the graphics are changed and rendered accordingly. Is this the approach you use when programming environments that the player can interact with?

It would make sense to have a global clock running, and as each predetermined unit of time passed, things would update. Of course, most of this code would be held in a while loop. I assume, though, that there's more than one way of doing this...? Pulling away from Minecraft and getting more general, if you wanted an "environment", you would have one main while loop that runs forever until you quit the game. And in this, there would be the code that handles things such as checking for player input, updating graphics, sound, AI, the player, etc.

The overall question, then, is what methods are there for programming graphical environments/environments the player can intuitively interact with? Is there a preferred method of doing things? If so, how would you go about programming that method?
Last edited on
Core Challenges with multithreading programming are to share data between threads , protecting their access integrity, debugging across threads and monitoring thread for dead-locks/starvation.
Do check out below relevant link as you are interested in C++ :-
Thanks for the article tajendra.

......One other thing I'm wondering is the asm integration in C++.
I've seen asm blocks before, and I've done asm for the SNES processor before, but I haven't done asm for today's processors. I wonder if there are any tutorials out there (probably).

Also, what would be the use for asm in C++? I know there are times when you need asm, but I can only recall one instance where a programmer had to get that low-level: it was for a Nintendo 64 Emulator. I just wonder what kind of situations would there be to have such precise memory control.
asm blocks in C++ are not portable, they are only used when the code is not meant to be portable and there is no API for what has to be done. You should avoid using asm blocks at all costs.
Last edited on
L B said:
You should avoid using asm blocks at all costs.

Well then.
Topic archived. No new replies allowed.