Question 2: Discuss the design,development, debugging,

and testing of concurrent software systems. Include in

discussion monitors, replayed shared variables and critical section.
Concurrent software systems are difficult to design, develop, debug, and test due to complex system states, increased complexity, and nondeterministic behavior just to name a few.
Concurrent systems are considered timing dependent which creates systems where bugs are
difficult to detect and reproduce. Concurrency is often achieved programmatically through
threads, monitors, and semaphores. Therefore the design of software engineering of concurrent systems is different than conventional systems. With the rapid uptake of multi-core
technology, developing concurrent systems is more important than ever.

2.1

Design

There are several design and modeling methods for concurrent systems, such as Concurrent
Design Approach for Real-Time Systems (CODARTS) and Concurrent Object Modeling and
Architectural Design Method (COMET). These methods account for only a few methodologies of design systems but it is beneficial to investigate these particular two in depth to give
a better idea of concurrent system design as a whole.

2.1.1

CODARTS

CODARTS emphasizes on information hiding and task structuring to realize a concurrent

design [2]. It emphasizes data-flow-oriented design to manage complexity. Information
hiding allows information that is only relevant to one module to not be shared between
other modules. It focuses on only the absolute required information to be passed between
systems. CODARTS allows access of information in message communication channels or
1

shared data pools to mitigate various communication issues in mutlithreaded environments.

Tasks should be structured depending on the dependency on I/O, Time-critical functions,
computational requirements, cohesion of functions and time, and periodic execution.

2.1.2

COMET

The COMET method uses the object oriented approach to systems design with a highly
iterative software life cycle [3]. It uses UML as its modeling method. COMET attempts to
differentiate from standard UML by allowing dynamic modeling of stochastic systems with
distribution and concurrency.

2.2

Development

Task synchronization is a common method when designing concurrent systems. Task synchronization is achieved in two ways: through mutual exclusion and cross stimulation[2].
Mutual exclusion is when shared data needs to be accessed by more than one process so each
process is policed individually. Cross stimulation is when one process is waiting on another.
During cross stimulation, semaphores or event synchronization can be used.

Task Communication is when one task needs to deliver information to another. The most
common form of task communication is message passing. A task that needs information can
wait in a queue of messages until it is populated.

A popular means to concurrent development is through high level abstraction of concurrent concepts in a programming language. Many languages have attempted allowing concurrent design such as GO and Haskell. The idea is to restrict programmers from making
bad decisions about concurrent development. Functional languages are a good candidate
for concurrent development as they do not have modifiable states. This drastically different
programming style restricts programs from being able to modify other functions so nonde2

terminacy becomes less of an issue.

Outside of languages, lock-free data structures are being developed to help spread workload
over multiple processes. One such structure call the lock-free bag allows multiple consumers
and producers that allows for a novel way of handling concurrent modification of certain
data structures [5]. These lock-free algorithms show a significant improvement in speed over
conventional algorithms by allowing more successful operations.

2.3

Debugging

Debugging concurrent systems can be very difficult due to its stochastic nature. Conventional testing may not be appropriate because it is difficult to get full code coverage because
of nondeterministic behavior. One method is replaying shared variables. This allows a way
to repeat execution in a controlled fashion. This allows testing of a function in a nondeterministic way. However, replaying shared variables is usually restricted to reproducing bugs
and usually show no indication of how to fix the bug [1].

2.4

Testing

Testing stochastic systems can be accomplished by formal proof, in-depth systematic testing,
and/or using detection algorithms. Formal proof is a viable alternative to complete systematic testing, as both types of testing are very high cost. As the level of testing increases, the
cost increases exponentially.

With systematic testing and using detection algorithms, testing all portions of code with
all circumstances can be very difficult. One approach is called reachability testing which attempts to test all reachable code. Some systems have been designed to allow for automatic
reachability testing but it can miss valid sequences of a specification if the implementation
is not correct [4].
3

References
[1] Gautam Altekar and Ion Stoica. Odr: output-deterministic replay for multicore debugging. In Proceedings of the ACM SIGOPS 22nd symposium on Operating systems
principles, SOSP 09, pages 193206, New York, NY, USA, 2009. ACM.
[2] H. Gomaa. A software design method for real-time systems. Commun. ACM, 27(9):938
949, September 1984.
[3] Hassan Gomaa. Designing concurrent, distributed, and real-time applications with uml.
In Proceedings of the 28th international conference on Software engineering, ICSE 06,
pages 10591060, New York, NY, USA, 2006. ACM.
[4] Yu Lei and Richard H. Carver. Reachability testing of concurrent programs. IEEE Trans.
Softw. Eng., 32(6):382403, June 2006.
[5] H
akan Sundell, Anders Gidenstam, Marina Papatriantafilou, and Philippas Tsigas. A
lock-free algorithm for concurrent bags. In Proceedings of the 23rd ACM symposium on
Parallelism in algorithms and architectures, SPAA 11, pages 335344, New York, NY,
USA, 2011. ACM.