Concurrency synchronization using uml state models
This presentation is the property of its rightful owner.
Sponsored Links
1 / 21

Concurrency/synchronization using UML state models PowerPoint PPT Presentation


  • 89 Views
  • Uploaded on
  • Presentation posted in: General

Concurrency/synchronization using UML state models. April 14 th , 2008 Michigan State University. Overview. State models of monitor objects Monitor-process pattern Heuristic for “generating” correct synchronization code from a state model

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Concurrency synchronization using uml state models

Concurrency/synchronization using UML state models

April 14th, 2008

Michigan State University


Overview

Overview

  • State models of monitor objects

    • Monitor-process pattern

    • Heuristic for “generating” correct synchronization code from a state model

    • Use of signal vs. broadcast to notify waiting threads

  • Examples

  • Synchronization that is more difficult to model using state diagrams


Method for using models to design concurrent software

Method for using models to design concurrent software

  • State model for each system object

    • Passive objects modeled using monitor-process pattern

  • Models then refined into code skeletons

    • Active objects incorporate infrastructure needed to host a thread:

      • E.g., a distinguished run method whose activation corresponds to the lifetime of a thread

    • Passive objects designed to behave as monitors

      • Design pattern for passive-object model guarantees monitor-object pattern can be applied to develop code

      • Guarded transitions in state model engender condition synchronization in code


Simple monitor process pattern

Simple monitor-process pattern

  • Simple pattern:

    • Distinguished initial state Idle

    • Composite state for each monitor operation

      • Reachable only from Idle via an accept-call action

        • Entry is named according to the name of the operation

        • Possibly guarded with an enabling condition

      • Must transition back to Idle via a reply action upon exit

        • Names the entry to which it corresponds

        • Includes return value (if any)

      • No accept-call actions within the composite state

  • Variations on this pattern will relax some of these restrictions


Simple monitor process pattern1

Simple monitor-process pattern

Monitor process

/ reply (op, result )

Idle

[guard] / accept-call ( op(parms) )

Operation body


Bounded buffer example

Idle

Bounded Buffer Example

BoundedBuffer

Pulling

[queue_.size != 0] /

accept-call ( pull )

do/ rv := queue_.pull

/ reply ( pull, rv)

/ reply ( push)

[queue_.size != MAX] /

accept-call ( push(x) )

Pushing

do/ queue_.push(x)


From simple monitor process to monitor object code

From simple monitor process to monitor object (code)

  • Class declares a private mutex variable lock

  • Each operation state in the model becomes a monitor method in the code

    • Method body bracketed by acquire/release of lock

  • If any transition out of Idle is guarded:

    • Class must declare a condition variable, associated with lock, to wait on when guard condition is NOT satisfied

    • Method body includes a conditionwait loop immediately following acquisition of lock

    • All other methods must notify this condition variable if they might serve to satisfy this guard condition

    • Notification could be signal or broadcast


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

}

Example: Code for Buffer::push

[queue_.size() != MAX]

/ accept-call (push(x))

Idle

/ reply (push)

Pushing

do/ queue_.push(x)


Example code for buffer push1

void Buffer::push(int x)

{

lock_.acquire();

while (queue_.size() == MAX) {

full_.wait();

}

queue_.push(x);

empty_.signal();

lock_.release();

}

Example: Code for Buffer::push

[queue_.size() != MAX]

/ accept-call (push(x))

Idle

/ reply (push)

Pushing

do/ queue_.push(x)


Example code for buffer push2

void Buffer::push(int x)

{

lock_.acquire();

while (queue_.size() == MAX) {

full_.wait();

}

queue_.push(x);

empty_.signal();

lock_.release();

}

Example: Code for Buffer::push

[queue_.size() != MAX]

/ accept-call (push(x))

Idle

/ reply (push)

Pushing

do/ queue_.push(x)


Example code for buffer push3

void Buffer::push(int x)

{

lock_.acquire();

while (queue_.size() == MAX) {

full_.wait();

}

queue_.push(x);

empty_.signal();

lock_.release();

}

Example: Code for Buffer::push

[queue_.size() != MAX]

/ accept-call (push(x))

Idle

/ reply (push)

Pushing

do/ queue_.push(x)


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;

}

Example: Code for Buffer::pull

[queue_.size() != 0]

/ accept-call (pull)

Idle

/ reply (pull, rv)

Pushing

do/ rv :=queue_.pull()


More complex guard conditions

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

Idle

Monitor-process model of BankAccount

BankAccount

Depositing

/ accept-call ( deposit(amount) )

do/ balance_ += amount;

/ reply ( deposit)

/ reply ( withdraw)

Withdrawing

[ amount <= balance_ ] /

accept-call ( withdraw(amount) )

do/ balance_ -= amount;


Code for bankaccount withdraw

void

BankAccount::withdraw(int amount)

{

lock_.acquire();

while (amount > balance_) {

okToWithdraw_.wait();

}

balance_ -= amount;

lock_.release();

}

Code for BankAccount::withdraw

[amount <= balance_]

/ accept-call (withdraw(amount))

Idle

/ reply (withdraw)

Withdrawing

do/ balance_ -= amount;


Code for bankaccount deposit

void

BankAccount::deposit(int amount)

{

lock_.acquire();

balance_ += amount;

okToWithdraw_.broadcast();

lock_.release();

}

Code for BankAccount::deposit

/ accept-call (deposit(amount))

Idle

/ reply (deposit)

Depositing

do/ balance_ += amount;


Signal vs broadcast

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?


More complex monitors

More complex monitors…

  • Simple monitor-process pattern insufficient for handling some forms of synchronization

    • E.g., barriers, using which two or more threads must arrive before either may pass

    • Not so easily modeled using guarded transitions

  • May require:

    • Embedding accept-call actions involving other operations within an operation state

    • Explicit modeling, storage, and retrieval of request objects associated with calls into an entry


Party admission problem

Party-admission problem

  • Models the admission of (boy–girl) couples to a party

    • Boys and girls arrive independently but are blocked from entering the party except as couples

    • When a boy arrives, he must block unless and until a girl has arrived for him to hook up with

    • Example of something called a barrier synchronization

  • Requires embedding accept-call action for girlArrives inside operation state for boyArrives and vice versa

    • Violates our simple monitor-process conventions

    • Still, may be modeled without too much trouble and without any use of guards on transitions


Example part of the model

Example: Part of the model

BoyWaiting

/ accept-call (girlArrives)

/ accept-call (boyArrives)

Idle

BoyMeetsGirl

/ reply (girlArrives)

/ reply (boyArrives)


Example other part of the model

Example: Other part of the model

GirlWaiting

/ accept-call (boyArrives)

/ accept-call (girlArrives)

Idle

BoyMeetsGirl

/ reply (boyArrives)

/ reply (girlArrives)


  • Login