Question:
What controls threads and dictates which set of instructions are placed as "threads"?
1970-01-01 00:00:00 UTC
What controls threads and dictates which set of instructions are placed as "threads"?
Three answers:
?
2013-08-23 23:30:23 UTC
> a thread is a group of instructions in such that this group is treated as a single unit of execution? - ok, can agree.



> If so then this must mean there is an organization of instructions into which we make these threads, right?

- Threads are constructs that are 'invented'/'made up' by the OS (aka. Windows/Linux/etc...) an os may have no threads at all whatsoever (although most modern os's have). For CPU, it's all a single flow of instructions one-at-a-time altogether (it isn't aware of any 'threads'). An os has a built in function, such as CreateThread on windows (see: http://msdn.microsoft.com/en-us/library/windows/desktop/ms682453%28v=vs.85%29.aspx ) or pthread_create on linux (http://man7.org/linux/man-pages/man3/pthread_create.3.html) that starts executing a specified group of instructions 'in parallel' with the first group (aka 'in parallel' with the one that called that CreateThread()).
Andrew
2013-08-23 22:48:48 UTC
Whichever software you use sends data to threads and back. If it was OS controlled everything would be multi threaded. Legacy programs used to all be single threaded.



You're mostly right on the basics of threading thoough.
Ratchetr
2013-08-23 16:35:03 UTC
I thread really isn't a group of instructions. It is more of an "execution context". Multiple threads may very easily be executing the same group of instructions.



A quick walkthrough of how an executable program is loaded and becomes a process might help. (To keep it simple, I will assume the program is compiled into an executable, not into byte code like Java or a .NET app. But the same basic principles apply to those apps as well).



A compiled executable is just a file. It is a bunch of binary data. In contains instructions (compiled code), and it includes data (things like string literals). It also contains metadata about the program that the OS uses to make sure everything is "glued together" properly.



When you launch a program, the OS will first allocate memory for that binary data, then read the file contents into memory (that is actually an oversimplification of what happens in a modern OS. But it is still conceptually true).



Once the program is loaded into memory, the OS will start running it. One of the things the metadata contains is the entry point for the program. This is just a memory address. Suppose the entry point is 0x12345. The OS will literally make a call to address 0x12345, and the program starts running.



At this point, there is only a single thread. It is the thread that started running at address 0x12345. As that code runs, it may very well make a call to the OS to create another thread. One of the things it has to tell the OS is where to start executing this new thread. It might tell the OS to start executing at address 0x54321. So the OS will then create a new execution context (all the information the OS needs to keep track of the thread), and then jump to address 0x54321. Now there are 2 threads running. The original that started the process, and the new one that started at 0x54321.



What instructions get executed by these threads is determined by the program. If the code that starts at 0x54321 makes a call to address 0x55555, then address 0x55555 will execute as part of that tread.



The main process may very well ask the OS to create many more threads. It can ask for more threads that start at address 0x54321. Each of these threads will be executing the same group of instructions.



One of the things the OS will store in the execution context of the thread is which instruction to execute next. (It stores this when it decides it is time to stop a thread from running. When it wants to resume that thread, it just picks up that address and jumps there). So it is the things in the execution context that make up a thread, not the specific set of instructions it will execute.



That is all a very gross simplification of how things really work. Things are a bit more complicated in the real world, but conceptually it is right.



Hope it makes some sense ;-)


This content was originally posted on Y! Answers, a Q&A website that shut down in 2021.
Loading...