| << Chapter < Page | Chapter >> Page > |
Experiment with the fork code in this chapter. Run the program multiple times and see how the order of the messages changes. Explain the results.
Experiment with the
create1 and
create3 codes in this chapter. Remove all of the
sleep( ) calls. Execute the programs several times on single and multiprocessor systems. Can you explain why the output changes from run to run in some situations and doesn’t change in others?
Experiment with the parallel sum code in this chapter. In the
SumFunc( ) routine, change the for-loop to:
for(i=start;i<end;i++ ) GlobSum = GlobSum + array[i];
Remove the three lines at the end that get the mutex and update the
GlobSum . Execute the code. Explain the difference in values that you see for
GlobSum . Are the patterns different on a single processor and a multiprocessor? Explain the performance impact on a single processor and a multiprocessor.
Explain how the following code segment could cause deadlock — two or more processes waiting for a resource that can’t be relinquished:
...
call lock (lword1)call lock (lword2)
...call unlock (lword1)
call unlock (lword2).
..
call lock (lword2)call lock (lword1)
...call unlock (lword2)
call unlock (lword1)... If you were to code the functionality of a spin-lock in C, it might look like this:
while (!lockword);
lockword = !lockword;
As you know from the first sections of the book, the same statements would be compiled into explicit loads and stores, a comparison, and a branch. There’s a danger that two processes could each load
lockword , find it unset, and continue on as if they owned the lock (we have a race condition). This suggests that spin-locks are implemented differently — that they’re not merely the two lines of C above. How do you suppose they are implemented?
Notification Switch
Would you like to follow the 'High performance computing' conversation and receive update notifications?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|