Threads - 3DSoftware.com

Threads

Previous Page:
Software

In the stored program model, a program is stored as data consisting of instructions for the computer to follow. The instructions are read sequentially from the memory where they are stored. A Program Counter (or Instruction Pointer) holds the address of (points to) the instruction being read, and is incremented to the next instruction after the instruction is read from memory.

This is said to be a thread of execution (or simply thread). The program is called a process and can have more than one thread. A thread only exists within its process. The threads of a process share the same process resources, as peers, allowing ease of communication between threads.

“A thread has access to all of the process's kernel object handles, all of the memory in the process, and the stacks of all other threads that are in the process.” [ 1 ]

A process (a regular program) can be called a heavy-weight process, and threads can be thought of as light-weight processes.

“A thread, sometimes called a lightweight process, is a basic unit of processor utilization… Context switching among peer threads is relatively inexpensive, compared to context-switching among heavy-weight processes.” [ 2 ]

Footnotes:

1.	Jeffrey Richter, Programming Applications for Microsoft Windows 4th Ed. (Microsoft Press, 1999), p. 187.

2.	El-Rewini & Abd-El-Barr, Advanced Computer Architecture and Parallel Processing (Wiley, 2005), p. 168.

Out-of-Order Execution

Each thread has its own Instruction Pointer. Consider for a moment only a single thread. The instructions are read in sequentially, but are not necessarily executed in that order.

Processors use a technique called pipelining in which an instruction starts executing before a previous instruction finishes execution. The previous instruction may take a long time and the next instruction could actually finish first.

That is just a simple explanation. There are actually variations of this. For example, to produce more efficient machine code the compiler could change the order of execution of your source code (static optimization) without disrupting dependencies between your variables: quicker instructions could be batched together from nearby code if other variables are not affected.

Or in dynamic scheduling, hardware instruction buffers are used, where instructions wait for their source operands to become available.

“An instruction may issue for execution as soon as its operands become available. Thus prior stalled instructions do not stall later independent instructions.” [ 1 ]

After execution, the instructions are commimitted (reordered to original order) in case an interrupt has to be processed. [ 2 ] And so the actual order of execution is irrelevant, because dependencies were tracked while the instructions were out-of-order. But this is only true within a thread. Dependencies between threads are not tracked. It is up to you, the application programmer, to track dependencies between threads.

1.	Eric Rotenberg and Aravindh Anantaraman, “Architecture of Embedded Microprocessors,” in Jerraya & Wolf (Eds.), Multiprocessor Systems-on-Chips (Morgan Kaufmann / Elsevier, 2005), p. 91

2.	Silc, Robic and Ungerer, Processor Architecture (Springer, 1999), p. 127.

Cache memory is on-chip memory that buffers data from larger off-chip memory. When the data that an instruction needs is already in cache memory, that is said to be a cache hit. If that data is not already in cache and must be fetched from off-chip memory, that is a cache miss and takes longer to process than a cache hit.

Dynamic scheduling of instructions is required to handle a cache miss. A cache miss cannot be predicted at compile time, and therefore cannot be handled with static optimization.

Automatically tracking dependencies between threads would make computers very inefficient. Yet it is easy for programmers to do that, since such dependencies are few.

Note that multi-threaded programs previously developed for uniprocessor systems (in which all threads run on the same processor) may behave differently when run on multiprocessor systems, in which case the secondary threads could run faster instead of slower than the program's main thread (possibly introducing new data consistency problems for the program).

Next Page:
Messaging