So far, we know: Wednesday, October 4, Thread_Programming Page 1

Transcription

1 Thread_Programming Page 1 So far, we know: 11:50 AM How to create a thread via pthread_mutex_create How to end a thread via pthread_mutex_join How to lock inside a thread via pthread_mutex_lock and pthread_mutex_unlock. And some basics of thread semantics: A thread shares everything but the stack with the main process. A thread cannot continue to run if the process dies. A thread can itself create threads and join threads. Threads created by a threads are threads of the process; there is no such thing as a thread of a thread. Threads don't -- without special preparation -- respond to signals.

2 Thread_Programming Page 2 Basic multi-threaded programming 11:53 AM The basic problem: a large computational problem in shared memory that can be broken into smaller problems to be solved somewhat independently. Example: make a list of all pictures in a directory with your face in them. Thread job: check out a few pictures per thread. Thread advantage: can be checking a picture while other threads are reading theirs into memory.

3 Thread_Programming Page 3 Put a picture into a list 11:57 AM char pictures[numpics][numchars]; int num_of_pics; void add_picture(const char *name) { (pictures[num_of_pics], name); num_of_pics = num_of_pics + 1; } This would seem a relatively innocent procedure, until you try to execute it in multiple threads. What can go wrong?

4 Thread_Programming Page 4 Some basic concepts of thread programming 11:56 AM A schedule is a depiction of what happens when between several threads. This is typically a table in which threads are in columns and instructions are in rows. A critical section is a fragment of code in which undesirable schedules can arise.

5 Are there harmful schedules? 12:03 PM void add_picture(const char *name) { (pictures[number_of_pics], name); number_of_pics = number_of_pics + 1; } Consider the following schedule:... other stuff... We lose the first completely in this schedule. There is a corrupt picture name in the array as well. (In case things weren't already bad enough.) Thread_Programming Page 5

6 How did that schedule happen? 1:07 PM... other stuff... Two context switches separate the and the for one of the threads. Not likely, but possible! In general, your analysis should consider whether a schedule is possible. The schedule is problematic but impossible; the scheduler will never context-switch that quickly. Thread_Programming Page 6

7 Thread_Programming Page 7 The basic principles of multithreaded programming 12:05 PM Identify critical sections in which undesirable schedules exist Surround critical sections with mutual exclusion locks to prohibit undesirable schedules. Minimize the time spent locked inside critical sections. With some important caveats: It is not possible to empirically determine a critical section. This is a theoretical result based upon the program's structure as assembly language. Some rather surprising things are critical sections.

8 Thread_Programming Page 8 A fairly simple fix to our program 12:08 PM void add_picture(const char *name) { pthread_mutex_lock(&lock); (pictures[num_of_pics], name); num_of_pics = num_of_pics + 1; pthread_mutex_unlock(&lock); } After this, the harmful schedule cannot happen, and only schedules like can happen.

9 Thread_Programming Page 9 Some facts about mutexes 12:10 PM Inserting a mutex always slows a program down, with the benefit of increasing determinism of the program. Code inside critical sections is serialized; only one core can enter a critical section at a time. Running slowly is better than losing data!

10 Thread_Programming Page 10 But wait, exactly what comprises a critical section? 12:12 PM Is num_of_pics = num_of_pics + 1; a critical section by itself? Depends on the computer's architecture! Suppose this is implemented in two-address assembler, e.g., as something like LDA #num_of_pics INCA STA #num_of_pics Is there a harmful schedule?

11 This is darn subtle! 12:14 PM Remember that the scheduler can stop execution of a thread and start execution for another thread at an unpredictable time. This happens at the boundary between two assembly-language instructions. We say that assembly language instructions are instructionally atomic, in the sense that an instruction is never halfcompleted. The instruction being executed when a context switch occurs either happens, or is interrupted before it does anything. Thus the following schedule is possible but very, very unlikely: LDA #num_of_pics INCA STA #num_of_pics LDA #num_of_pics INCA STA #num_of_pics... other stuff... And we lose an! Thread_Programming Page 11

12 Thread_Programming Page 12

13 Thread_Programming Page 13 So, 12:20 PM You don't need to lock around single instructions, but you do need to lock around sequences of instructions that act on the same data; these are critical. Most lines of C are compiled into more than one instruction!

14 Secrets of locking 12:22 PM The locking mechanism itself depends upon this fact. All mutexes are implemented by some form of "test-set" instruction. test-set #address if #address is 0, then set it to 1 if #address is 1, do nothing. In the same instruction, put old value into a register (usually an accumulator). How this works: If the accumulator is 0 and the memory is 1, you got the lock. In any other case, you didn't get the lock. pthread_mutex_lock exploits this by reserving a piece of memory and checking its state. A simple theoretical fact: if several threads race to employ test-set, exactly one of them wins the race and the lock. The rest are "too late", in the sense that the memory is already 1. Thread_Programming Page 14

15 Thread_Programming Page 15 What happened in assignment 1 12:30 PM In assignment 1, you observed that successful calls to pthread_mutex_lock use only user time. Why? From the point of view of the thread, If the mutex is unlocked, test-set succeeds. Thus "you get the lock". You haven't made a system call. If the mutex is not unlocked or you lose the race, test-set fails. Thus your thread blocks. At this point, you need to call the kernel to block yourself! Caveat: if there are few races, mutexes are super-efficient, requiring only two machine instructions to lock and one to unlock. (The second instruction compares the accumulator to the memory location to see if you got the lock)

16 So, is a line of C -- by itself -- ever atomic? 12:39 PM Perhaps, but it is very bad form to presume this. It depends upon the architecture. Consider, e.g., ++number_of_pics; which might be implemented as either LDA #number_of_pics INCA STA #number_of_pics or INCI #number_of_pics // immediate In the former case, it's not atomic. In the latter case, it is. However, and this is very important -- the latter case violates the semantics of C. ++i is supposed to leave the value of i in a register! So, it's actually rather difficult to assure that a single line of C is atomic! Thread_Programming Page 16

17 Thread_Programming Page 17 Heisenbugs 12:49 PM Heisenberg's uncertainty principle: It is not possible to measure the position of an electron without changing that position. Inspired by the uncertainty principle, a "Heisenbug" is a bug in a program that is exceedingly difficult to reproduce. It might do something bad one time in a million. Only solution is to reason properly about the position of the critical section, to prevent that very unlikely schedule from ever happening.

18 Thread_Programming Page 18 Facts about Heisenbugs 12:55 PM It is not possible to find Heisenbugs through debugging. Their nature is to be difficult to observe. One must instead analyze the code theoretically. (you knew theory was good for something! :) More generally, it is necessary to use theory to determine that a locking scheme is deadlock-free.