Inherent Multithreading &OSes

[Ryoutarou97]

So when talking about which CPU to go with, everyone's always talking about how games aren't multithreaded. I'm not much of a programer (I have studied it a bit, enough to somewhat understand how software works, but not very into it or by any means an expert.) but I do understand the concept of multithreading. I was wondering, why is it done by the OS. Why does software have to be multi threaded. Surely the OS could just have 4 or 8 or 72 threads going at all time (or some of the time for power constraints, I guess) and just send instructions to them in turn (or in some system thought out by people much smarter than me.) Is there another name for this that I just don't know about? 

[Stuff_]

It's a tough question to answer on the forms, and likely not many people here (besides maybe Linus himself, maybe) can give you a proper answer.

 

You'll likely need to fall back on a textbook to get your answer.

[skyress3000]

I'll explain what little of this I do know, while giving the disclaimer that I'm not an expert and I'm probably wrong in some way or another. You can append an "(I think)" onto the end of all of the following sentences.

 

The OS does put different applications on different threads, hence Linus' testing showing that having more threads improves performance while doing a bunch of stuff all at the same time. However, one program has to run on one thread (or however many it was designed to) because all the stuff happening in one thread needs to be in the same context, which doesn't happen across multiple cores. For example, supposed I have a simple program which is a set of instructions. My first instruction is "create a variable called bob". This is executed on Thread #1 and now there is a variable called bob in the context of Thread #1. My next instruction, "assign the string 'hello i am bob' to variable bob" is executed on Thread #2. However, Thread #2 says "hey, there's no variable called bob!" because it wasn't created on Thread #2 and my program crashes. In contrast, I can write a program that is specifically designed to execute tasks on different threads. For example, a rendering application could assign a portion of the frame (think of Cinebench and its little rectangles) to each thread, and it would be fine as it is built so that the threads do not need to reference each other.

[trag1c]

Threading is done on the kernel level so there is not exactly threads per se since when you create a thread at the user level you are simply telling the kernel to schedule the task for a different core or virtual core than what the main application is running on. So the OS maintains multiple threads while the processes them selves simply schedule a task which the kernel then determines when and where that task will be executed.

 

Also @skyress3000 said is more or less correct. 

 

When a multithreaded program creates a variable it has to worry about who is using the variable and by who I mean threads.

e.g. If Thread A is reading from Variable abc while Thread B is writing to it there will be big issues with data corruption. 

To remedy that issue programs either have to isolate data running on different threads or the have to have synchronization points which the threads can "talk" with each other. This is where a lot of the complexity of multithreading is shown. This can cause a big burden since there is no way of knowing when a task will be executed and when it will be finished. Since different tasks all coded differently can take different number of CPU cycles to execute which all have different places in queue.