Concurrency/synchronization using UML state models and sequence models: A brief review April 21 st, 2008 Michigan State University

Simple monitor-process pattern Idle [guard] / accept-call ( op(parms) ) / reply (op, result ) Monitor process Operation body

Bounded Buffer Example / reply ( pull, rv ) BoundedBuffer Idle [queue_.size != 0] / accept-call ( pull ) Pulling do/ rv := queue_.pull Pushing do/ queue_.push(x) / reply ( push ) [queue_.size != MAX] / accept-call ( push(x) )

Example: Code for Buffer::push void Buffer::push(int x) { lock_.acquire(); while (queue_.size() == MAX) { full_.wait(); } queue_.push(x); empty_.signal(); lock_.release(); } Idle [queue_.size() != MAX] / accept-call (push(x)) Pushing do/ queue_.push(x) / reply (push)

Example: Code for Buffer::push void Buffer::push(int x) { lock_.acquire(); while (queue_.size() == MAX) { full_.wait(); } queue_.push(x); empty_.signal(); lock_.release(); } Idle [queue_.size() != MAX] / accept-call (push(x)) Pushing do/ queue_.push(x) / reply (push)

Example: Code for Buffer::push void Buffer::push(int x) { lock_.acquire(); while (queue_.size() == MAX) { full_.wait(); } queue_.push(x); empty_.signal(); lock_.release(); } Idle [queue_.size() != MAX] / accept-call (push(x)) Pushing do/ queue_.push(x) / reply (push)

Example: Code for Buffer::push void Buffer::push(int x) { lock_.acquire(); while (queue_.size() == MAX) { full_.wait(); } queue_.push(x); empty_.signal(); lock_.release(); } Idle [queue_.size() != MAX] / accept-call (push(x)) Pushing do/ queue_.push(x) / reply (push)

Example: Code for Buffer::pull int Buffer::pull() { lock_.acquire(); while (queue_.size() == 0) { empty_.wait(); } int rv = queue_.pull(); full_.signal(); lock_.release(); return rv; } Idle [queue_.size() != 0] / accept-call (pull) Pushing do/ rv := queue_.pull() / reply (pull, rv)

More complex guard conditions Consider a banking application that allows multiple clients to deposit and withdraw funds from shared accounts Goals: Protect against data races, so that money is not accidentally created or destroyed Prevent overdrafts by making withdraw requests block if account has insufficient funds Question: How should we model the behavior of an account object?

Monitor-process model of BankAccount / reply ( deposit ) BankAccount Idle / accept-call ( deposit(amount) ) Depositing do/ balance_ += amount; Withdrawing do/ balance_ -= amount; / reply ( withdraw ) [ amount <= balance_ ] / accept-call ( withdraw(amount) )

Code for BankAccount::withdraw void BankAccount::withdraw(int amount) { lock_.acquire(); while (amount > balance_) { okToWithdraw_.wait(); } balance_ -= amount; lock_.release(); } Idle [amount <= balance_] / accept-call (withdraw(amount)) Withdrawing do/ balance_ -= amount; / reply (withdraw)

Code for BankAccount::deposit void BankAccount::deposit(int amount) { lock_.acquire(); balance_ += amount; okToWithdraw_.broadcast(); lock_.release(); } Idle / accept-call (deposit(amount)) Depositing do/ balance_ += amount; / reply (deposit)

Signal vs. Broadcast When one thread changes the value of a condition upon which others might be waiting, the modifier is obliged to notify these waiting threads Always safest, though perhaps not very efficient, to use broadcast to notify waiting threads after a change Question: When is it safe to use signal?

“Mixed” Monitor objects Some methods on a monitor class may be “non-monitor methods” Do not acquire / release mutex lock Multiple threads may access simultaneously Threads may access non-monitor methods while 1 thread in a monitor method 1 thread may enter monitor method while other threads in non-monitor method