Cs 704 d set3


Published on

Published in: Education
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Cs 704 d set3

  1. 1. CS 704DAdvanced Operating System<br />Debasis Das<br />
  2. 2. Tools for Implementationof Semaphores #3<br />Compare & Swap Instructions<br />Helps consistent update of global variable<br />Implementation<br />Compare Oldreg, Globvar<br />Set condition codes<br />If (Oldreg=Globvar) Then Globvar Newreg<br /> Else OldregGlobvar<br />MIT CS704D Advanced OS Class of 2011<br />2<br />
  3. 3. Queuing Implementationof Semaphore<br />MIT CS704D Advanced OS Class of 2011<br />3<br />Semaphore<br />Pz<br />…..<br />Py<br />Px<br />Wait(s): If not (s>0) then suspend caller at s<br /> else s:= s+1<br />Signal (s): if queue is not empty (at least one process is waiting)<br /> then resume process from the queue at s<br /> else s:=s+1<br />
  4. 4. Overview of Classical Synchronization problems<br />Producers and consumers<br />With unbounded buffers<br />With bounded buffers<br />Readers and writers<br />MIT CS704D Advanced OS Class of 2011<br />4<br />
  5. 5. Producers & Consumers<br />One class of processes produce data items<br />The other class consumes/uses this data<br />They may have different rates and thus cause synchronization problems<br />Synchronizations required so that producers & consumers are able to operate concurrently<br />Such that items produced are consumed in the same order<br />Display, keyboard was an example<br />Processes may be a combination of both producer and consumer<br />MIT CS704D Advanced OS Class of 2011<br />5<br />
  6. 6. Producers & Consumers(unbounded buffer case)<br />If we can prevent a process trying to consume something before at least one item is available, sync is achieved<br />A semaphore “Producer” can take care of that<br />We assume buffer manipulation does not cause problems<br />This is not really a valid assumption in multiple producer, consumer situations<br />MIT CS704D Advanced OS Class of 2011<br />6<br />
  7. 7. Unbounded Buffer Case<br />A mutex controlling buffer access can manage the situation well<br />How the mutex is used exactly can have unintended implications<br />If the waiting on “producer” is placed within the critical section, there can be deadlocks<br />Initially, for example, when nothing has been produced and a consumer is scheduled, the consumer will get through to the critical section<br />Then wait forever on Producer as a producer process cannot get into the critical section<br />MIT CS704D Advanced OS Class of 2011<br />7<br />
  8. 8. Producers & Consumers(bounded buffer case)<br />Additional management issues are that the buffers are to be controlled<br />Producers should not produce when buffer is full, it will overwrite some existing data<br />Consumers, similarly will consume wrong data if buffer is empty<br />These conditions have to be controlled<br />MIT CS704D Advanced OS Class of 2011<br />8<br />
  9. 9. Unbounded case <br />Icount=produced-consumed<br />Necessary that icount cannot be less than zero and more than the capacity<br />Then<br />Condition mayproduce : icount < capacity<br /> as also mayconsume: icount>0<br />MIT CS704D Advanced OS Class of 2011<br />9<br />
  10. 10. Readers & Writers<br />Readers and consumers are processes that operate against some common data structure<br />Readers are pure readers, only reads parts or all of the data structure<br />Writers write and thus modify the data structure. It can also read the structure or parts of it<br />Readers thus can safely get interleaved with other readers<br />But writes cannot be interleaved with other readers or writers<br />MIT CS704D Advanced OS Class of 2011<br />10<br />
  11. 11. The sync Problem<br />Given a universe of readers that read a common data structure, and a universe of writers that modify the same common data structure<br />A sync mechanism needs to be devised to control readers and writers to ensure consistency of common data and maintain as high a concurrency as possible<br />MIT CS704D Advanced OS Class of 2011<br />11<br />
  12. 12. Example Synchronization<br />High concurrency<br />Allows high number of readers to access common resource<br />Writer waits for the wait semaphore<br />Reader process makes it possible for multiple readers to work<br />Readercount really tracks if even one reader is active<br />Next round, the writer gets turn only when all readers finished reading, that may be unfair<br />MIT CS704D Advanced OS Class of 2011<br />12<br />
  13. 13. Suggested Modifications(according to C A R Hoare)<br />A reader should not start if there’s a writer waiting, preventing starvation for writers<br />All readers waiting at the end of a write cycle should be given priority, preventing starvation of readers<br />MIT CS704D Advanced OS Class of 2011<br />13<br />
  14. 14. Inter-process Communication& Synchronization<br />MIT CS704D Advanced OS Class of 2011<br />14<br />
  15. 15. Semaphore Problems<br />Sync and system integration depend on strict following of the discipline and implementation. Forgetting of either of wait and signal mechanism, reversing or going around it will cause problems in the system<br />Semaphores control access to shared resources but cannot prevent misuse of the same by some process granted access to these global variables.<br />MIT CS704D Advanced OS Class of 2011<br />15<br />
  16. 16. Critical Regions & Conditional critical Regions<br />Strong typing and compile time checks can prevent some of the problems<br />For example var mutex : shared T; and critical section as follows <br />region mutex do<br />The compiler can ensure wait and signals are introduced properly, no probability of errors<br />MIT CS704D Advanced OS Class of 2011<br />16<br />
  17. 17. Why condionality required<br />Sometimes a process getting access to the CS may still need some condition to be fulfilled and thus block other processing entering the CS<br />Conditional CS construct can prevent such problems<br />MIT CS704D Advanced OS Class of 2011<br />17<br />
  18. 18. Conditional Critical Region<br />var mutex: shared T;<br />begin <br />region v do<br />begin<br />await condition<br />end;<br />End;<br />Special queue is maintained, allowed only when the condition is met<br />MIT CS704D Advanced OS Class of 2011<br />18<br />
  19. 19. Monitor<br />MIT CS704D Advanced OS Class of 2011<br />19<br />Enforce concurrency<br />Processes<br />Processes<br />Access, modify shared variable(s)<br />
  20. 20. Monitors-Plus Minus<br />Can regulate a group of related resources too<br />If this is too many, the serialization overhead could be too much<br />Same things can be done at kernel level<br />Serialization overheads will cause problems very quickly as kernel controls all kinds of resources<br />Writing, building, debugging such monolithic structures could be problematic<br />Monitors can create a deadlock<br />Monitor disciplines may restrict application programmers<br />MIT CS704D Advanced OS Class of 2011<br />20<br />
  21. 21. Messages<br />A collection of data, execution commands, sometimes even code<br />Interchanged between sending and receiving processes<br />MIT CS704D Advanced OS Class of 2011<br />21<br />Sender id<br />Receiver id<br />Length<br />Header<br />Type<br />……<br />Message body<br />
  22. 22. Issues in Message Implementation<br />Naming<br />Direct, indirect (mailbox)<br />Copying<br />Copy message, pass pointer<br />Synchronous/asynchronous<br />Synchronous can be blocking, asynchronous can cause runaway, indefinite postponement<br />Length<br />Fixed or variable length (overhead vs. flexibility)<br />MIT CS704D Advanced OS Class of 2011<br />22<br />
  23. 23. Inter-process Communication & sync with Messages<br />Assume buffered message, infinite channel capacity, indirect naming (via mailboxes)<br />Sender send s the message & continues, receiver will be suspended if no message<br />Sync through semaphore like operation of messages. Signal send a message to waiting on semaphore, wait is just waiting to receive a message<br />Sync also can be through messages<br />Example; producer waits for a message through mayproduce mailbox, a consumer gets a mayconsume<br />MIT CS704D Advanced OS Class of 2011<br />23<br />
  24. 24. Interrupt Signaling via Message<br />A message (signal) can initiate a set of waiting interrupt service processes<br />Interrupt service need not be treated differently from other processes<br />Hardware interrupts that need guaranteed response time, may be a problem<br />All software interrupts can be handled this way<br />MIT CS704D Advanced OS Class of 2011<br />24<br />
  25. 25. Deadlocks<br />A deadlock is a situation where processes are permanently blocked as a result of each process having acquired a subset of the resources needed for its completion and waiting for the release of the remaining resources held by others in the same group- thus making it impossible for any of the processes to proceed.<br />MIT CS704D Advanced OS Class of 2011<br />25<br />
  26. 26. Necessary Conditions<br />Mutual exclusion. Shared resources are used exclusively by at most one process at a time.<br />Hold & Wait. Resources already allocated are held by the process and waits for the balance to be acquired<br />No preemption. Resources are released only when given up by the owner<br />Circular waiting. Each process hold one or more resources being requested by the next process in the chain<br />MIT CS704D Advanced OS Class of 2011<br />26<br />
  27. 27. Reusable & Consumable Resources<br />Reusable. Resources that can be safely used by one process at any time.<br />It is either available or allocated to a process<br />It can only be relinquished by the owner<br />Single resource multiple instances, multiple resources of single instance<br />Consumable resources. Once consumed, these do not exist any more; example messages. Deadlocks can happen, such as a receiver waiting for a message. OS must intervene to break such deadlocks.<br />MIT CS704D Advanced OS Class of 2011<br />27<br />
  28. 28. Deadlock Prevention-1<br />Hold-an-wait condition can be resolved by forcing release of all other held resources when the process requests for a resource that is not available.<br />Request all resources prior to execution<br />Asks for resources as needed but relinquishes resources held by it when a requested resource is not available<br />Overestimation of resources, holding on to resources longer than necessary<br />Reduces concurrency, resources are underutilized<br />MIT CS704D Advanced OS Class of 2011<br />28<br />
  29. 29. Deadlock Prevention-2<br />No-preemptionissue can obviously be solved by allowing preemption<br />OS will need to save the state of the process<br />For some resources the preemption may not be a problem, like CPU and memory pages but resources like files cannot be safely preempted without corrupting the system<br />Apply such policies only when the benefits of deadlock prevention is more than the cost of save & restore of state of some resources<br />MIT CS704D Advanced OS Class of 2011<br />29<br />
  30. 30. Deadlock Prevention-3<br />Circular wait. Request resources of a higher class only after the resources from a lower class has been acquired successfully. All requests in a given class must be acquired through a single request.<br />The prescribed ordering can be checked at compile time, avoiding run time problems<br />Disadvantages<br />All resources must be acquired up front<br />Lower degree of concurrency and lower utilization of resources<br />MIT CS704D Advanced OS Class of 2011<br />30<br />
  31. 31. Deadlock Avoidance<br />Grant resources only if the request is not likely to cause deadlocks<br />A resource allocator must examine the implications<br />All processes must proclaim maximum need<br />When requested, the resource allocator must check if the other executing processes can safely complete (they have resource allocation pending) . If not the process should wait.<br />MIT CS704D Advanced OS Class of 2011<br />31<br />
  32. 32. Deadlock detection & Recovery<br />If the general resource graph has a cycle or a knot then deadlock exists<br />Rollback or restarting can be options<br />State needs to be known<br />Some systems have check pointing or journaling system, one could use that<br />MIT CS704D Advanced OS Class of 2011<br />32<br />
  33. 33. Combined Approach<br />Typical classes of devices<br />Swap area<br />Job resources & assignable devices<br />Main memory (by page, segment etc.)<br />Internal resources such as I/O channels, buffer pool etc.<br />Deadlock prevention between the main classes, deadlock handling within each class is used<br />MIT CS704D Advanced OS Class of 2011<br />33<br />
  34. 34. Combined Policies<br />Swap space: advance booking of all swap space. Dead lock detection is not possible<br />Job resources: pre-claiming of resources, Resource ordering also is possible. Detection combined with recovery is undesirable, as can have repercussions on file resources<br />Main memory : preemption is used but not avoidance as that has run time overheads and resource underutilization<br />Internal system resources : avoidance or detection will have performance penalties. Prevention by means of resource ordering is typically done<br />MIT CS704D Advanced OS Class of 2011<br />34<br />