Concurrency/synchronization using UML state models

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

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

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

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 sd scenario n b : sharedBuffer c : Consumer startWrite() startRead() 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.

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

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

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

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 } }

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

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

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

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

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.

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: • 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 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)

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

Concurrency/synchronization using UML state models