1 / 32

Concurrency/synchronization using UML state models

This article provides an overview of concurrency and synchronization in programming using UML state models, including threads, monitors, condition synchronization, and application of UML 2.0 state diagrams. November 27th, 2007, Michigan State University.

echesney
Download Presentation

Concurrency/synchronization using UML state models

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. Concurrency/synchronization using UML state models November 27th, 2007 Michigan State University

  2. Overview • Programming model used to implement multi-threaded concurrency • Threads • Monitors • Condition synchronization • Application of UML 2.0 state diagrams to model and reason about concurrent interactions

  3. Overview • Programming model used to implement multi-threaded concurrency • Threads • Monitors • Condition synchronization • Application of UML 2.0 state diagrams to model and reason about concurrent interactions

  4. Thread Concepts • A thread is always in one of three states: context switch running ready context switch signal wait suspended

  5. p:Producer Sequence diagram sd scenario n Passive object Active object b : sharedBuffer c : Consumer startWrite() thread is ready thread is running startRead() Thread is suspended Thread is not running in this object Snapshot of execution in progress

  6. Thread Concepts: Context Switch • A context switch is the simultaneous transitioning of: • one thread from the ready state to the running state • AND • the previously running thread from the running state to another state (ready or suspended).

  7. p:Producer sd scenario n b : sharedBuffer c : Consumer startWrite() startRead() Producer switches out, consumer switches in … Consumer suspends, producer switches in …

  8. Monitors • Class-like programming construct that allows at most one thread to execute concurrently • Implemented by associating a lock with each monitor object • Threads that execute the methods of a monitor object must: • obtain the monitor lock before doing anything else in the method • release the lock just prior to returning.

  9. Monitor Synchronization • When a thread attempts to acquire a monitor lock that is held by another thread: • the thread that made the failed attempt suspends (i.e., changes state from running to suspended). • If the operating system causes a thread running within a monitor to yield (context switch out), the thread will not release the lock before yielding.

  10. sd scenario6 State labels - producer enters and obtains lock : LineProducer : BoundedBuffer : LineConsumer putLine(“d”) locked; getLine() Consumer fails to obtain the lock; suspends unlocked; Producer releases lock before returning

  11. Condition Synchronization • Counting variables are used to encode the synchronization state of a shared resource. • Conditions are predicates formed over one or more counting variables. • Condition variables are associated with conditions and used: • by a waiting thread to register interest in a change in the associated condition • CV.wait() • by a running thread to inform registered waiting threads of changes in the associated condition. • CV.signal() • CV.broadcast()

  12. Producer-Consumer Example void BoundedLineBuffer::putLine(unsigned id, const string& line){ ACE_Guard<MonitorLockType> guard(lock_); while (isFull()) { // condition: buffer full? cout << "WAIT-ON-FULL: Producer #" << id << endl; fullCond.wait(); // operation on condition variable } buf.push_back(line); cout << "PRODUCE: Producer #" << id << " " << "(buf.size = "<< buf_.size() << ")" << endl; if (buf.size() == 1) { // counting variable: num elements in buffer emptyCond_.broadcast(); } }

  13. sd scenario2 :LineConsumer : BoundedBuffer okToRead: … : LineProducer getLine() locked; size=1; locked; size=0; unlocked; Size=0; getLine() locked; size=0; wait() unlocked; size=0; putLine() locked; size=0; locked; size=1; broadcast() unlocked; Size=1; …Locked, then unlocked

  14. Producer Consumer Example void BoundedLineBuffer::getLine(unsigned id, string& line){ ACE_Guard<MonitorLockType> guard(lock_); while (isEmpty()) { // condition: buffer state cout << "WAIT-ON-EMPTY: Consumer #" << id << endl; emptyCond_.wait(); } line = buf_.front(); buf_.pop_front(); cout << "CONSUME: Consumer #" << id << " " << "(buf.size = "<< buf_.size() << ")" << endl; if (buf_.size() == capacity_ - 1) //counting variable = num elements in buffer { fullCond_.broadcast(); // operation on condition variable } }

  15. sd scenario2 :LineConsumer : BoundedBuffer okToRead: … : LineProducer getLine() locked; size=1; locked; size=0; unlocked; Size=0; getLine() locked; size=0; wait() unlocked; size=0; putLine() locked; size=0; locked; size=1; Broadcast() unlocked; Size=1; …Locked, then unlocked

  16. Wait on a Condition Variable • Waiting on a condition variable causes a thread to: • release its hold on the monitor lock • change state from running to suspended • When a call to wait returns, the calling thread will be back in the monitor • will have reacquired the monitor lock

  17. sd scenario2 :LineConsumer : BoundedBuffer okToRead: … : LineProducer getLine() locked; size=1; locked; size=0; unlocked; Size=0; getLine() locked; size=0; wait() unlocked; size=0; putLine() locked; size=0; locked; size=1; broadcast() unlocked; Size=1; …Locked, then unlocked

  18. Signal on a condition variable • Signaling a condition variable: • changes to ready the state of some thread that is suspended waiting on this variable • does not cause signaling thread to release the monitor lock. • does not cause the signaling thread to change its state • is a necessary but not sufficient condition to cause another thread to return from a call to wait on that variable

  19. sd scenario2 :LineConsumer : BoundedBuffer okToRead: … : LineProducer getLine() locked; size=1; locked; size=0; unlocked; Size=0; getLine() locked; size=0; wait() unlocked; size=0; putLine() locked; size=0; locked; size=1; Broadcast() unlocked; Size=1; …Locked, then unlocked

  20. Condition Synchronization • programmed using a loop • guard checks the condition • body executes a wait on condition variable. while (isEmpty()) { // condition: buffer state cout << "WAIT-ON-EMPTY: Consumer #" << id << endl; emptyCond.wait(); // suspended (on wait) -> ready (on signal) -> // running (on context switch) -> re-acquire monitor lock } • return from wait indicates that associated condition was true at some point between invocation of wait and return. • BUT -- some other thread could have made the condition false before the waiting thread obtains monitor lock • SO: the thread must check that the associated condition remains true • THUS: it is important to place the wait inside a loop.

  21. sd scenario2 :LineConsumer : BoundedBuffer okToRead: … : LineProducer getLine() locked; size=1; locked; size=0; unlocked; Size=0; getLine() locked; size=0; wait() unlocked; size=0; putLine() locked; size=0; locked; size=1; Broadcast() unlocked; Size=1; …Locked, then unlocked

  22. Overview • Programming model used to implement multi-threaded concurrency • Threads • Monitors • Condition synchronization • Application of UML 2.0 state diagrams to model and reason about concurrent interactions

  23. Overview • Programming model used to implement multi-threaded concurrency • Threads • Monitors • Condition synchronization • Application of UML 2.0 state diagrams to model and reason about concurrent interactions

  24. Analytical models of behavior UML sequence diagrams useful for • documentation/explanation • “roughing out” a design prior to implementation But they are not very rigorous: • Depict only one scenario of interaction among objects • Not good for reasoning about space of possible behaviors Such reasoning requires more formal and complete models of behavior

  25. UML 2.0 State Models • Used to model concurrent designs • Abstract away much of the ugliness associated with the multi-threaded programming model • Allow reasoning about space of behaviors of an object and of concurrent, interacting objects • Key idea: Each object modeled by a communicating sequential process • Processes are inherently concurrent with one another • Note: Even a “passive” object is modeled by a process • Processes communicate by sending and receiving one-way, asynchronous signals • More complex modes of interaction (e.g., rendezvous) built atop the signaling facilities

  26. Key terms Event: instantaneous occurrence at a point in time • receipt of an asynchronous signal • e.g., alarm raised, powered on • onset of a condition • e.g., paper tray becomes empty • execution of some action or effect State: behavioral condition that persists in time • waiting for arrival of one or more asynchronous signals and/or the onset of one or more conditions • period during which some activity is being performed Transition: instantaneous change in state • triggered by an event

  27. State diagrams Graphical state-modeling notation: • States: labeled roundtangles • Transitions: directed arcs, labeled by signal occurrence, guard condition, and/or effects Example: Event signal(attribs) [guard-condition] / effect S T States Transition

  28. Events run to completion Run-to-completion semantics: • State machine processes one event at a time and finishes all consequences of that event before processing another event • Events do not interact with one another during processing Pool: • Where new incoming signals for an object are stored until object is ready to process them • No arrival ordering assumed in the pool

  29. Example C S C1 init / v :=0 / send S.init S1 C2 seed(x) / v := x S2 / send S.seed(100) C3 / send C.rand (v+3) seed(x) / v := x rand(x) [x > 1] / send S.seed(x/10)

  30. Modeling method invocations Given state machines for two objects C and S, where C is the client and S the supplier of a method m • Model the call as a signal that requests the operation on behalf of the client • Model return as a reply from the supplier to the client • C should send the request to S and then await the reply • This protocol of interaction is called a rendezvous

  31. UML 2.0 support for rendezvous • UML implements rendezvous using: • Call activities, performed by the client • Accept-call and reply actions, performed by the supplier

  32. Example C S S2 do/ v := v+3 reply (rand,v) C1 do/ call S.seed(100) / accept-call (rand) Idle C2 do/ x := call S.rand() / accept-call (seed(x)) S1 do/ v := x reply(seed)

More Related