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
Collaboration Of Objects 2


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.
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.
2.
3.
At synchronization points, register
Pass their callbacks
i.e. notify() called once condition met
Rendezvous Pattern – Collaboration
Roles II
Rendezvous

1.
2.
Manages thread synchronization
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



Concrete Thread



Super class for concrete thread
Interface to the scheduler
<<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 objectoriented 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?