Page 151 - DCAP308_OBJECT_ORIENTED_ANALYSIS_AND_DESIGN

Unit 12: System Design

12.2.3 Identifying Concurrency Notes

In the analysis model, as the real world and in hardware, all objects are concurrent. In an
implementation, not all software objects are concurrent, because one processor may support
many objects. One important goal of the system design is to identify the objects that must be
active concurrently and the objects that have mutually exclusive activity.

Identifying inherent concurrency: The state model is the guide to identifying concurrency. Two
objects are inherently concurrent if they can receive events at the same time without interacting.
If events are unsynchronized, you cannot fold the objects onto a single thread of control.

Inherent Concurrency

May involve synchronization.
Multiple objects receive events at the same time without interacting.

Example: User may issue commands through control panel at same time that the sensor
is sending status information to the Safe Home system.

Determining Concurrent Tasks

Thread of control
Path through state diagram with only one active object at any time

Threads of control are implemented as tasks
Interdependent objects
Examine state diagram to identify objects that can be implemented in a task

Concurrency Testing Tools

There are a number of concurrency testing tools on the market to help you deal with potential
deadlocks, live locks, hangs, and all the other issues you experience when running parallel
transactions. Each tool we look at here will help in a particular area.
1. CHESS: Created by Microsoft Research, CHESS is a novel combination of model checking
and dynamic analysis. It detects concurrency errors by systematically exploring thread
schedules and interleaving. It is capable of finding race conditions, deadlocks, hangs, live
locks, and data corruption issues. To help with debugging, it also provides a fully repeatable
execution. Like most model checking, the systematic exploration provides thorough
coverage.
As a dynamic analysis tool, CHESS runs a regular unit test repeatedly on a specialized
scheduler. On every repetition, it chooses a different scheduling order. As a model checker,
it controls the specialized scheduler that is capable of creating specific thread interleaving.
To control the state space explosion, CHESS applies partial-order reduction and a novel
iteration context bounding.
In iteration context bounding, instead of limiting the state space explosion by depth,
CHESS limits number of thread switches in a given execution. The thread itself can run
any number of steps between thread switches, leaving the execution depth unbounded (a
big win over traditional model checking). This is based on the empirical evidence that a
small number of systematic thread switches is sufficient to expose most concurrency bugs.

LOVELY PROFESSIONAL UNIVERSITY 145