Concurrency/synchronization using UML state models November 27th, 2007 Michigan State University

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

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

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

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

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).

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

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.

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.

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

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()

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();

: BoundedBuffer okToRead: … : LineProducer 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; saUdL for Q7 locked; size=1; broadcast() unlocked; Size=1; …Locked, then unlocked

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

: BoundedBuffer okToRead: … : LineProducer 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; saUdL for Q7 locked; size=1; Broadcast() unlocked; Size=1; …Locked, then unlocked

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

: BoundedBuffer okToRead: … : LineProducer 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; saUdL for Q7 locked; size=1; broadcast() unlocked; Size=1; …Locked, then unlocked

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

: BoundedBuffer okToRead: … : LineProducer 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; saUdL for Q7 locked; size=1; Broadcast() unlocked; Size=1; …Locked, then unlocked

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.

: BoundedBuffer okToRead: … : LineProducer 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; saUdL for Q7 locked; size=1; Broadcast() unlocked; Size=1; …Locked, then unlocked

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

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

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

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

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

State diagrams Graphical state-modeling notation: Example: 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

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

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

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

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

Example C S S2 C1 Idle C2 S1 reply (rand,v) do/ v := v+3 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)