Concurrency Design Patterns

By:

Kalpana Nallavolu

Nestor Rivera

Feras Batarseh

Design Patterns

A design pattern is a formal way of documenting successful solutions to problems.

Reusability, modularity, win time.

Resign Pattern Ex: fatal, misbehavior.

Contributors

Christopher Alexander

GoF

Concurrency Design Patterns Concurrency Pattern Message Queuing Pattern Interrupt Pattern Guarded Call Pattern Rendezvous Pattern Cyclic Executive Pattern Round Robin Pattern Static Priority Pattern Dynamic Priority Pattern

Background

Thread Concurrency Concurrency Architecture Active Object Passive objects

Collaboration Of Objects

The active object accept messages and delegate them to the internally contained application objects for processing.

The issues around the concurrency management are varied depending

1) The threads are completely independent

2) The threads are not really independent.

Collaboration Of Objects 2

Message Queuing Pattern

Message Queuing Pattern

It provides a simples means of communication among threads.

It uses asynchronous communication. Information shared among threads is passed

by value to the separate thread. Advantages and disadvantages

Pattern Structure

Sample Model

Interrupt Pattern

Interrupt Pattern

In many real-time applications, certain events must be responded quickly and efficiently regardless of what system is doing.

This method is rarely used as only concurrency strategy

Advantages and disadvantages.

Pattern Structure

Sample Model

Guarded Call Pattern

Guarded Call Pattern – Abstract Problem with Message Queuing Pattern…?

Asynchronous & slow What if urgency? Alternative -> synchronously

invoke a method of an object Data integrity is key -> mutual exclusion Need to avoid ->synchronization & deadlock

problems

Guarded Call Pattern – Collaboration Roles I Server Thread: <<active object>>

Server Object Shared Resource Protection with Mutex

Client Thread: <<active object>> Client object Synchronously invoke method

Guarded Call Pattern – Collaboration Roles II Boundary Object

Protected interface to server objects with operations Mutex

Mutual exclusion semaphore object Permits only single caller through time Safer if invoked by relevant operations Locks and unlocks shared resource Blocks client threads

Guarded Call Pattern – Collaboration Roles III Server

Uses the shared resource object Provides the service to client across the thread boundary

Shared Resource Provides data or service Shared by multiple servers Integrity must be protected => serialization of access

Guarded Call Pattern - Consequences

Timely response (unless services are locked) Simplification: no interaction among servers

=> boundary object, contain shared resource & one mutex/server

Guarded Call Pattern – Related Patterns Message Queuing, Interrupt, Guarded Call &

Rendezvous could be mixed Race conditions may appear If server is stateful, monitor on server may be

needed

Guarded Call Pattern – Class Diagram

Guarded Call Pattern Example - Structure

Guarded Call Pattern Example - Scenario

Rendezvous Pattern

Rendezvous Pattern

Simplified form of Guarded Call Pattern (synchronize threads)

Rendezvous Object => means for synchronization (synchronization point, policy or precondition)

Rendezvous Pattern - Abstract Precondition => specified to be true prior to

an action/activity Behavioral model => each thread registers

with Rendezvous class and blocks until released

Rendezvous Pattern – Collaboration Roles I Callback: holds address of client thread Client Thread

1. At synchronization points, register

2. Pass their callbacks

3. i.e. notify() called once condition met

Rendezvous Pattern – Collaboration Roles II Rendezvous

1. Manages thread synchronization

2. Has register() operation Sync Policy

1. Reifies set of preconditions into single concept i.e. Registration count (Thread Barrier Pattern)

Rendezvous Pattern – Class Diagram

Rendezvous Pattern – Sync Policy State Chart

Rendezvous Pattern Example - Structure

Rendezvous Pattern Example - Scenario

Cyclic Executive Pattern

Cyclic Executive Pattern

Very small systems (execution predictability is crucial)

Easy to implement Can run in memory constraint systems (no

RTOS) Executes tasks in turn, from first to last and

starts over again (cycle)

Cyclic Executive Pattern – Collaboration Roles Abstract Thread

Super class for concrete thread Interface to the scheduler

Concrete Thread <<active object>> Contains passive objects

Scheduler Initializes system (loads tasks) Runs each of them in turn in perpetuity

Cyclic Executive Pattern – Properties of Applications Constant number of tasks Amount of task time is unimportant or

consistent Tasks are independent Usage of shared resources complete after

each task Sequential ordering of tasks is adequate

Cyclic Executive Pattern – Pros and Cons Primary advantage => simplicity Primary Disadvantages

Lack of flexibility Non-optimality Instability to violation of its assumptions

Response to incoming event: deadline >= cycle time No criticality or urgency: all threads are equally

important.

Cyclic Executive Pattern – Class Diagram

Cyclic Executive Pattern Example - Structure

Cyclic Executive Pattern Example - Scenario

Round Robin Pattern

Introduction

Hardcore real time deadline! A “fairness” scheduling method. All tasks progress than specific deadline to

be met. Entire set movement.

The Model

Abstract thread: super class, associates with scheduler.

Concrete thread: (active thread) real work of the system.

Scheduler: initialize the tasks and run them. Stack: control and data; variables, return variables Task control block Timer: ticks for scheduler, front end to the hardware

timer, switch task();

Pros and Cons

All tasks get the chance to run. Misbehaving task wont ruin the system. Scale up better to big systems. Higher switching time… All tasks take the same time slice!

Priority?

Related Patterns

More complex than cyclic executive Less complex than priority patterns,

discussed next. Special kind that gives each task its time.

Static Priority Pattern

Introduction

Priorities predefined. Common approach, simple, large number of

tasks. Urgency (time) + Criticality (importance)

The Model

Abstract thread Blocked queue: queue for TCB, blocked tasks in,

out to ready queue. Concrete thread Shared resources Mutex: semaphore object that allows one caller

object (thread) to access shared resources.

Mutex ID, entry point.

The Model 2

Ready queue: reference to tasks ready to execute next.

even running tasks could be interrupted by looking at the RQ.

Scheduler: calls start address of higher and ready thread.

Stack: parameters for threads. Task control block: priority and entry address

Pros and Cons

Simplicity Stability Changing conditions, reallocation? (DPP) Low priority tasks?

Dynamic Priority Pattern

Introduction

Automatically update of tasks priorities. Urgency over criticality, thus Earliest deadline

first. Sets priority as time remaining function.

The Model

Abstract thread Blocked queue: queue for TCB, blocked tasks in,

out to ready queue. Concrete thread Ready queue: reference to tasks ready to execute

next, closest to deadline on top.even running tasks could be interrupted by looking at the RQ.

The Model 2

Scheduler: computes the priority dynamically due to closest deadline.

Stack: return addresses and parameters for threads. Task control block: priority and entry address after

scheduler computations. Shared resources Mutex: semaphore object that allows one caller

object (thread) to access shared resources.

Pros and Cons

Flexible Optimal Scales well to large systems Not stable Complex

Related Patterns

Not as common as SPP More complex than other patterns

References

[book] Real time design patterns: Patterns: robust scalable architecture for real-time systems

[book] Design patterns: Elements of reusable object-oriented software

Gomma, Hassan Software Design Methods for concurrent and real timeSystems, Reading , Addison-Wesley 1993

IEEE Papers Database wikipedia.com...and a couple of other websites

Thank you for your attention.

Questions?