1 / 40

Software Architecture and Larger System Design Issues Lecture 3: Synchronization

Software Architecture and Larger System Design Issues Lecture 3: Synchronization. Topics: Concurrent access to shared objects Thread synchronization Monitors. Outline of course topics. Foundational OO concepts Synthetic concepts Software architecture and larger design issues

teal
Download Presentation

Software Architecture and Larger System Design Issues Lecture 3: Synchronization

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Software Architecture and Larger System Design Issues Lecture 3:Synchronization Topics: Concurrent access to shared objects Thread synchronization Monitors CSE 335: Software Design

  2. Outline of course topics • Foundational OO concepts • Synthetic concepts • Software architecture and larger design issues • Example concern: Implementing systems with multiple loci of control • Active objects • Techniques for implementing active objects: • Have one actor (e.g., the GUIManager) periodically “cede” small quanta of control to other actors, which must be designed to perform their task in a series of small steps • Allocate a system thread to “power” an actor • Software process issues CSE 335: Software Design

  3. Concurrent access to shared data • Problem: Multiple active objects might access the same passive object “at the same time” • Generally OK if the active objects are only reading data from the passive object(s) • but even this can be dangerous if the “reader” methods use iterators or some other mutable operation • But if one or more active objects is modifying the data members of the shared object, then we get anomalies • Example: Two active objects trying to pull elements from the same queue • To prevent these data-access anomalies requires synchronizing the active objects. CSE 335: Software Design

  4. : Queue actor1 : … actor2 : … Example pull pull Suppose Queue initially contains <“hello”, “world”, “foo”>. What are the possible outcomes? CSE 335: Software Design

  5. Possible outcomes • Actor1 gets “hello”, actor2 gets “world”, queue contains <“foo”> • Actor1 gets “world”, actor2 gets “hello”, queue contains <“foo”> • Both actor1 and actor2 get “hello”, queue contains <“world”, “foo”> • Other possibilities, including corruption of internal state of queue... CSE 335: Software Design

  6. : Queue actor1 : … actor2 : … Question: Is this interaction possible? pull pull CSE 335: Software Design

  7. The sad news… • While the use of multiple threads is very powerful, to avoid errors requires: • Reasoning that “breaks” modularity, i.e., thinking about how methods are implemented and how methods they invoke are implemented • Reasoning about a large number of possible thread interleavings CSE 335: Software Design

  8. Example • class Queue { • public: • … • bool pull( string& s ) • { bool retval = q.empty(); • if (!retval) { • s = q.back(); • q.pop(); • } • return retval; • } • … • protected: • queue<string> q; • }; CSE 335: Software Design

  9. Example interleaving actor1 : … :Queue actor2 : … pull empty pull empty back pop Question: What happens if queue contains A ? back pop CSE 335: Software Design

  10. Example interleaving actor1 : … :Queue actor2 : … pull empty pull empty back pop Question: What happens if queue contains A, B ? back pop CSE 335: Software Design

  11. What can go wrong here? Queue contains: A,B,C actor1 : … :Queue actor2 : … pull empty pull empty back back pop pop CSE 335: Software Design

  12. To prevent unsafe interleavings • Promote shared object into a monitor • high-level synchronization construct • contains an implicit lock – only one thread can be executing within the monitor at one time • Concurrent activations of monitor operations: • execute in some order without overlap • i.e., are serialized but the exact order of execution is not defined • Note: There is an extension to monitors that allows control over this ordering CSE 335: Software Design

  13. Potential scenario actor1 : … :MonitorQueue actor2 : … pull empty pull back pop empty back pop CSE 335: Software Design

  14. Another potential scenario actor1 : … :MonitorQueue actor2 : … pull pull empty back pop empty back pop CSE 335: Software Design

  15. Thread synchronization • Definitions: • Critical section: region of code in which at most one thread should be allowed to execute concurrently • Mutex lock: OS facility used to synchronize threads • One and only one thread can own a lock • Thread comes to own a lock by acquiring it • A thread will block if it attempts to acquire a lock owned by another thread • Important: Whenever you write multi-threaded programs, you must identify and protect critical sections in your code! CSE 335: Software Design

  16. Multi-threaded programming • C++ provides no language features for thread programming • Contrast with Java, which does provide such features • In C++, threads and thread operations are provided by standard libraries • In Unix, standard threads library is “pthreads” • Short for POSIX threads • Include files: /usr/include/pthread.h • Link library: libpthreads.a • A more object-oriented solution is the ACE library, built atop pthreads CSE 335: Software Design

  17. Primitives for using mutex locks • ACE_Thread_Mutex: type used to declare a lock • acquire: acquires a lock, blocking if lock owned by another thread • release: releases a lock, so that other threads may acquire it CSE 335: Software Design

  18. Exercise • Modify the design of the Queue class to protect its critical section(s) with locks. CSE 335: Software Design

  19. Answer • class ThreadSafeQueue { • public: • ThreadSafeQueue() {} • … • bool pull( string& s ) • { • lock.acquire(); • bool retval = q.empty(); • if (!retval) { • s = q.back(); • q.pop(); • } • lock.release(); • return retval; • } • protected: • ACE_Thread_Mutex lock; • queue<string> q; • }; CSE 335: Software Design

  20. Monitor synchronization • Defn:Monitor is an object whose methods may not be executed by multiple threads concurrently • Example: • Let o be a monitor that provides the operation: void foo() • Suppose threads T1 and T2invoke o.foo() at nearly the same time • One thread (e.g., T1) will be allowed to “enter the monitor”; the other (e.g., T2) must wait • Most OO languages use monitor synchronization CSE 335: Software Design

  21. The monitor-object pattern • Standard pattern for making instances of an arbitrary class behave like monitors. • Let C be the original class, and Mbe the (new) monitor class: • M should inherit publicly from C • M should contain a protected data member (call it lock) of type ACE_Thread_Mutex • For each public method m of C, M should override that method with one that acquires lock, invokes C::m and then releases lock CSE 335: Software Design

  22. Exercise • Use the monitor-object pattern to produce an alternative version of ThreadSafeQueue by extending the original Queue class. CSE 335: Software Design

  23. Answer • class MonitorQueue : public Queue { • MonitorQueue() {} • ~MonitorQueue() {} • bool pull( string& s ) • { • lock.acquire(); • bool retval = Queue::pull(s); • lock.release(); • return retval; • } • protected: • ACE_Thread_Mutex lock; • }; CSE 335: Software Design

  24. Design uses of synchronization • Monitors used to control access to shared data by preventing two threads from executing same method simultaneously. • Provides a very primitive form of coordination among active objects • In more complex interactions, an actor might wish to “wait” for another actor to perform some task and be “signaled” when once the other actor completes the task • We refer to this as condition synchronization CSE 335: Software Design

  25. Example • Suppose we are implementing a web server that accepts incoming network connections containing http requests and processes these requests in order • Requests take some time to perform, so to be fair, we would like to “queue them up” upon arrival and dispatch them in order CSE 335: Software Design

  26. Example interaction netSensor : … :Buffer reqHdlr : … push empty pull handle push push push empty pull CSE 335: Software Design

  27. Another example interaction netSensor : … :Buffer reqHdlr : … push empty pull handle push push CSE 335: Software Design

  28. Another example interaction netSensor : … :Buffer reqHdlr : … empty empty empty empty empty empty empty empty empty CSE 335: Software Design

  29. Issues • Obviously, buffer needs to be a monitor • We might also like to reduce the useless work performed by reqHdlr when the buffer is empty • Likewise might wish to start dropping requests when the buffer is full • Somehow, the state of the buffer needs to affect the execution of netSensor and reqHdlr CSE 335: Software Design

  30. Condition synchronization • Another form of synchronization that allows threads to “give up” a mutex lock and go to sleep until later notified by another thread CSE 335: Software Design

  31. Condition variables • Objects that attempt to reify conditions or states of other objects for the purpose of synchronization • Implementation: • ACE_Condition_Thread_Mutex used to declare a condition variable (parameterized by a lock) • wait causes invoking thread to “go to sleep” and release the lock until such time as some other thread invokes the signal operation on the condition variable • signal wakes one of the waiting threads, and makes it enter into contention for the lock CSE 335: Software Design

  32. Declaration of class Buffer • class Buffer { • public: • Buffer(); • void push( const string & ); • bool pull( string& ); • bool empty(); • protected: • queue<string> requestQ; • ACE_Thread_Mutex lock; • ACE_Condition_Thread_Mutex fullCond; • ACE_Condition_Thread_Mutex empty; • }; CSE 335: Software Design

  33. Declaration of class Buffer • class Buffer { • public: • Buffer(); • void push( const string & ); • bool pull( string& ); • bool empty(); • protected: • queue<string> requestQ; • ACE_Thread_Mutex lock; • ACE_Condition_Thread_Mutex fullCond; • ACE_Condition_Thread_Mutex empty; • }; Declares monitor lock CSE 335: Software Design

  34. Declaration of class Buffer • class Buffer { • public: • Buffer(); • void push( const string & ); • bool pull( string& ); • bool empty(); • protected: • queue<string> requestQ; • ACE_Thread_Mutex lock; • ACE_Condition_Thread_Mutex fullCond; • ACE_Condition_Thread_Mutex empty; • }; Declares 2 condition variables (full & empty) CSE 335: Software Design

  35. Example • void Buffer::push( const string & s ) • { lock.acquire(); • while(requestQ.full()) • fullCond.wait(); • requestQ.push_back(s); • if (requestQ.size() == 1) emptyCond.signal(); • lock.release(); • } CSE 335: Software Design

  36. Example • void Buffer::push( const string & s ) • { lock.acquire(); • while(requestQ.full()) • fullCond.wait(); • requestQ.push_back(s); • if (requestQ.size() == 1) emptyCond.signal(); • lock.release(); • } Acquires monitor lock Releases monitor lock CSE 335: Software Design

  37. Example • void Buffer::push( const string & s ) • { lock.acquire(); • while(requestQ.full()) • fullCond.wait(); • requestQ.push_back(s); • if (requestQ.size() == 1) emptyCond.signal(); • lock.release(); • } Waits signal from another thread CSE 335: Software Design

  38. Example • void Buffer::push( const string & s ) • { lock.acquire(); • while(requestQ.full()) • fullCond.wait(); • requestQ.push_back(s); • if (requestQ.size() == 1) emptyCond.signal(); • lock.release(); • } Signals any thread blocked on the empty condition CSE 335: Software Design

  39. Notes • Critically important to embed the wait of a condition variable in a loop that checks the logical negation of the condition • Reason: A significant amount of time could pass between when waiting thread is signaled and it reacquires the lock • Possible that the condition might no longer be true when the thread awakens CSE 335: Software Design

  40. Exercise • Design the logic for Buffer::empty so that the caller will block (go to sleep) when the buffer is empty CSE 335: Software Design

More Related