( do_one_thing uses r1 as a counter do_another_thing uses r2.) Both threads can refer to the same file descriptors and other resources the system maintains for the process. Each thread can refer to global variables in the same data area. Thread 1, the thread in which the program was started, is executing do_one_thing, while Thread 2 is executing do_another_thing. (It’s certainly very handy for a thread to keep track of the instruction it is currently executing and where in the stack area it should be pushing and popping its procedure-context information.) This allows Thread 1 and Thread 2 to execute at different locations (or exactly the same location) in the program’s text. Here, each thread has its own copy of the machine registers. It is only when we design our program to take advantage of multiple threads in the same process that the thread model really takes off.įigure 1-3 shows our program as it might execute if it were designed to operate in two threads in a single process. As a process with a single thread, this program executes in exactly the same way as it does when modeled as a nonthreaded process.
As far as the outside observer of the program is concerned, nothing much has changed. Here, the machine registers (program counter, stack pointer, and the rest) have become part of the thread, leaving the rest as the process. Process-specific include tables, maintained by the operating system, to track system-supplied resources such as open files (each requiring a file descriptor), communication end points (sockets), locks, and signalsįigure 1-2 shows the same C program as a process with a single thread. Machine registers, including a program counter (PC) to the currently executing instruction and a pointer (SP) to the current stack frame The threads model takes a process and divides it into two parts: In the threads model, multiple subtasks exist as individual streams of control within the same process. Now, we’ve been given an alternative that’s even more efficient and provides even better performance for our overall program-threads. In this model, each subtask must exist within its own process. Specifically, we started designing programs in which parent processes forked child processes to perform subtasks. Up until now, when we divided our program into multiple tasks, we had only one way of delivering them to the processor-processes. Either way, we’ll see a performance boost. On some systems, the execution of subtasks will be interleaved on a single processor on others, they can run in parallel. If we can get the computer to execute some of these subtasks at the same time, with no change in our program’s results, our overall task will continue to get as much processing as it needs, but it will complete in a shorter period of time. For instance, if our program is a marine navigation system, we could launch separate tasks to perform each sounding and maintain other tasks that calculate relative depth, correlate coordinates with depth measurements, and display charts on a screen. Today, it’s frequently useful to look at our program (our very big task) as a collection of subtasks. One of those capabilities is a computing system’s ability to perform multitasking.
If all of our programs run like this, we’re very likely not using our computer to its fullest capabilities.
#How to compile pthread c program serial
When we package our work according to the traditional, serial notion of a program, we’re asking the computer to execute it close to the humble performance of a computer of yesterday. Today’s computers can do many things at once (or very effectively make us believe so). Since then, computers have become more and more powerful and grown more efficient at performing the work that makes running our programs possible. Not too many years ago, single instructions were how we delivered work to computers. But we have one way into our program, regardless of its spins and hops, and one way out.
If programming instructions were squares on a game board, we can see that our program has places where we stall, squares that we cross again and again, and spots we don’t cross at all. Our notion of a program can include certain eccentricities, like loops and jumps, that make a program more resemble a game of Chutes and Ladders than a piano roll. When describing how computers work to someone new to PCs, it’s often easiest to haul out the old notion that a program is a very large collection of instructions that are performed from beginning to end. Specifying Potential Parallelism in a Concurrent Programming Environment
0 kommentar(er)
