Threads and Critical SectionsGedankenthreadsMechanicsThread and Address SpaceConcurrency and ThreadsTypical Thread APIUser vs. Kernel-Level ThreadsThread Control BlockThreads Backed By Kernel Threads“Too Much Milk” ProblemA Possible Solution?Another Possible Solution?Yet Another Possible Solution?RemarksWhat Is A Good SolutionPrimitivesThe Simplistic Acquire/ReleaseDisabling InterruptsUsing Disabling InterruptsSlide 20Hardware Support for MutexThe Big PictureAtomic Read-Modify-Write InstructionsA Simple Solution with Test&SetTest&Set, Minimal Busy WaitingThreads and Critical SectionsVivek Pai / Kai LiPrinceton University2GedankenthreadsWhat happens during fork?We need particular mechanisms, but do we have options about what to do?3MechanicsMidterm grading finish26-30: 131-35: 436-40: 241-45: 546-50: 351-55: 756-60: 661-65: 666-70: 671-75: 776-80: 1Quiz still not graded4Thread and Address SpaceThreadA sequential execution stream within a process (also called lightweight process)Address spaceAll the state needed to run a program Provide illusion that program is running on its own machine (protection)There can be more than one thread per address space5Concurrency and ThreadsI/O devicesOverlap I/Os with I/Os and computation (modern OS approach)Human usersDoing multiple things to the machine: Web browserDistributed systemsClient/server computing: NFS file serverMultiprocessorsMultiple CPUs sharing the same memory: parallel program6Typical Thread APICreationFork, JoinMutual exclusionAcquire (lock), Release (unlock)Condition variablesWait, Signal, BroadcastAlertAlert, AlertWait, TestAlert7User vs. Kernel-Level ThreadsQuestionWhat is the difference between user-level and kernel-level threads?DiscussionsWhen a user-level thread is blocked on an I/O event, the whole process is blockedA context switch of kernel-threads is expensiveA smart scheduler (two-level) can avoid both drawbacks8Thread Control BlockShared informationProcessor info: parent process, time, etcMemory: segments, page table, and stats, etcI/O and file: comm ports, directories and file descriptors, etcPrivate stateState (ready, running and blocked)RegistersProgram counterExecution stack9Threads Backed By Kernel ThreadsEach thread hasa user stacka private kernel stackProsconcurrent accesses to system servicesworks on a multiprocessorConsMore memoryEach thread hasa user stacka shared kernel stack with other threads in the same address spaceProsless memoryDoes not work on a multiprocessorConsserial access to system services10“Too Much Milk” ProblemDon’t buy too much milkAny person can be distracted at any pointPerson A Person BLook in fridge: out of milkLeave for WawaArrive at WawaBuy milkArrive homeLook in fridge: out of milkLeave for WawaArrive at WawaBuy milkArrive home11A Possible Solution?Thread can get context switched after checking milk and note, but before buying milkif ( noMilk ) { if (noNote) { leave note; buy milk; remove note; }}if ( noMilk ) { if (noNote) { leave note; buy milk; remove note; }}12Another Possible Solution?Thread A switched out right after leaving a noteThread Aleave noteAif (noNoteB) { if (noMilk) { buy milk }}remove noteAThread Bleave noteBif (noNoteA) { if (noMilk) { buy milk }}remove noteB13Yet Another Possible Solution?Safe to buyIf the other buys, quitThread Aleave noteAwhile (noteB) do nothing;if (noMilk) buy milk;remove noteAThread Bleave noteBif (noNoteA) { if (noMilk) { buy milk }}remove noteB14RemarksThe last solution works, butLife is too complicatedA’s code is different from B’sBusy waiting is a wastePeterson’s solution is also complexWhat we want is:Acquire(lock);if (noMilk) buy milk;Release(lock);}Critical section15What Is A Good SolutionOnly one process inside a critical sectionNo assumption about CPU speedsProcesses outside of critical section should not block other processesNo one waits foreverWorks for multiprocessors16PrimitivesWe want to avoid thinking (repeatedly)So, we want some “contract” that provides certain behaviorLow-level behavior encapsulated in “primitives”Application uses primitives to construct more complex behavior17The Simplistic Acquire/ReleaseKernel cannot let users disable interruptsCritical sections can be arbitrarily longUsed on uniprocessors, but won’t work on multiprocessorsAcquire() { disable interrupts;}Release() { enable interrupts;}18Disabling InterruptsDone right, serializes activityPeople think sequentially – easier to reasonGuarantees code executes without interruptionDelays handling of external eventsUsed throughout the kernel19Using Disabling InterruptsWhy do we need to disable interrupts at all?Why do we need to enable interrupts inside the loop in Acquire?Acquire(lock) { disable interrupts; while (lock != FREE){ enable interrupts; disable interrupts; } lock = BUSY; enable interrupts;}Release(lock) { disable interrupts; lock = FREE; enable interrupts;}20Using Disabling InterruptsWhen does Acquire re-enable interrupts in going to sleep?Before enqueue?After enqueue but before block? Acquire(lock) { disable interrupts; while (lock == BUSY) { enqueue me for lock; block; } else lock = BUSY; enable interrupts;}Release(lock) { disable interrupts; if (anyone in queue) { dequeue a thread; make it ready; } lock = FREE; enable interrupts;}21Hardware Support for MutexMutex = mutual exclusionEarly software-only approaches limitedHardware support became commonVarious approaches:Disabling interruptsAtomic memory load and storeAtomic read-modify-writeL. Lamport, “A Fast Mutual Exclusion Algorithm,” ACM Trans. on Computer Systems, 5(1):1-11, Feb 1987. – use Google to find22The Big PictureConcurrent ApplicationsLocks Semaphores Monitors Send/ReceiveLoad/Store Interrupt disable Test&SetHigh-LevelAtomic APILow-LevelAtomic OpsInterrupt (timer or I/O completion), Scheduling, Multiprocessor23Atomic Read-Modify-Write InstructionsTest&Set: Read value and write 1 back to memoryExchange (xchg, x86 architecture)Swap register and memoryCompare and Exchange (cmpxchg, 486+)If Dest = (al,ax,eax), Dest = SRC; else (al,ax,eax) = DestLOCK prefix in x86Load link and conditional store (MIPS, Alpha)Read value in one instruction, do some operationsWhen store, check if value has been modified. If not, ok; otherwise, jump back to start24A Simple Solution with Test&SetWaste CPU timeLow priority threads may never get a chance to runAcquire(lock) {