25 - Synchronization ProblemsOutlinePthread APIDining PhilosophersAnnouncementsReading:DeadlockOther Synchronization ProblemsPthreads APIMutexCondition VariablesExample: Producer-ConsumerExerciseDeadlockOther Synchronization ProblemsStarvation vs. DeadlockManaging DeadlockCan two threads in the same process synchronizeusing a kernel mutex if threads are implemented bythe kernel?Assume no other processes access the mutex.What if the threads are implemented in user space?Famous synchronization problem proposed andsolved by Dijkstra in 1965.5 philosophers are seated at a round table.Each philosopher has a bowl of ramen, and betweeneach bowl is one chopstick.Philosophers alternate between thinking andeating. When a philosopher wants to eat, theyattempt to acquire the adjacent chopsticks oneat a time, in either order.If they are successful, they will eat for some time,then put down their chopsticks.Can a program be written to represent allphilosophers that guarantees a philosopher willnever get stuck?A set of processes is deadlocked if each processin the set is waiting for an event that can only becaused by another process in the set.one philosopher has adjacent philosophers whoconspire to alternate eatingall philosophers attempt to take the right (orleft) chopstick simultaneouslyglobal lock (one philosopher eats at a time)(correct, but poor performance)(correct, but also poor worst case)eat if neither neighbor is eatingbreak symmetry (pick lower chopstick index)track global state of each philosophera philosopher never releases chopsticksOriginally slippery spaghetti with 2 forks, but this makes muchmore sense to me.PollEvPthread mutex can be created statically ordynamically, and must be initialized before use.When finished with a mutex, it must bedestroyed, since initialization can requireallocation.When finished with a condition variable, it mustbe destroyed, since initialization can requireallocation.Destroying a locked mutex is undefined behavior!Destroying a condition variable with waitingprocesses is undefined behavior!Waiting with an unlocked mutex is UB!pthread_mutex_initpthread_mutex_destroypthread_mutex_lockpthread_mutex_trylockpthread_mutex_unlockpthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;(Mutex can have optional object attributes)pthread_mutex_t mutex;pthread_mutex_init(&mutex, &attr);blockingStaticDynamicnon-blockingDining Philosophers1)3)4)2)MOS 6.1 - 6.4, 6.7.4PA 4 instructions releasedpthread_cond_initpthread_cond_destroypthread_cond_waitpthread_cond_signalpthread_cond_broadcastblockswakes one threadwakes all threadsPthread condition variables can also be createdstatically or dynamically, and must be initializedbefore use.pthread_cond_t c = PTHREAD_COND_INITIALIZER;(condition variables can also have optional object attributes)pthread_mutex_t c;pthread_mutex_init(&c, &attr);StaticDynamicpthread_cond_wait(&condition, &mutex)Must be called with mutex locked.A)A)B)B)C)C)YesYesNoNoIt DependsIt DependsP0c1c2c3c4c0P1P2P3P42 issuesSolutionsWhat are the potential issues?->>>>>>-StarvationDeadlockMOS solution:Conditions necessary for deadlock:1)2)3)4)Mutual Exclusioneach resource is either available or currentlyassigned to exactly one process.processes currently holding resources canrequest new resources.previously granted resources cannot beforcibly released.there exists a circular chain in which eachprocess holds a resource requested by thenext process in the chain.Hold and WaitNo PreemptionCircular WaitStarvation is characterized by indefinite waiting.Deadlock is characterized by circular waiting.Reactive strategies (allow deadlocks to occur)Proactive strategiesMost major OS use Ostrich algorithmWe've looked at:Other famous problems:Deadlock ===> StarvationStarvation =/=> Deadlocka.k.a. Coffman Conditions>>>>--------------1.2.Ostrich algorithm: ignore the problemAvoidancePreventionDetect and Recovergrant resource only if deadlock impossiblee.g. Dijkstra's Banker's Algorithmforce 1 resource at a time,allow resource preventionNegate one of Coffman conditionsReasonable if deadlock is rare or prevention isprohibitively expensiveProducer-Consumer problemSleeping Barber problemABA problemCigarette Smokers problemReaders-Writers problemDining Philosophers problemTradeoff between convenience and correctnessProgrammer's responsibility to do it rightbuild resource allocation graph, look forcycles (expensive to do often)break deadlockrevoke resource (may break program)rollback process (difficult and expensive)kill process (simple, may break application)e.g.