Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼

Cameron and Tracey Hughes

Dr. Dobb's Bloggers

Testing and Logical Fault Tolerance for Parallel Programs

June 17, 2011

The goal of testing software is to make sure that the software does what we want and we want what is does. An application is often requested as a list of desired features. This list can be represented as a formal specification consisting of hundreds of pages, or can be as simple as verbal requests from an employer detailing a dozen or so requirements.

Regardless of how the list of requirements for a piece of software is generated, the testing process must make sure that the software meets those requirements and that the requirements meet the user's expectations. In many cases where parallel computers or multiprocessors are involved, the user's expectations include performance speed gains or a certain level of high performance throughput. The kinds of software errors will increase when multithreading or multiprocessing is added in attempts to achieve the user's expectation.

When the software does not perform according to the specifications, the software is in error — even if the specification violation is that the system performs too slowly. Testing and debugging are in the top ten challenges for software that has a concurrency requirement. Software that requires parallel programming can be notorious to test and debug. We use exception handling to provide a kind of logical fault-tolerance for declarative architectures. That is, if our application for unknown and uncontrollable reasons violates statements, assertions, rules, predicates, or constraints from our PBS (Predicate Breakdown Structure), we want to throw an exception and gracefully exit because once our predicates have been violated, then the correctness, reliability, and meaning of the application has been compromised. The journey towards fault tolerance in our software begins by recognizing that:

  • No amount of exception handling can rescue a flawed or inappropriate software architecture
  • The fault tolerance of a piece of software is directly related to the quality of its architecture
  • The exception handling architecture cannot replace the testing stages

In our approach toward declarative interpretations of parallel programming, we are moving more toward logical models. Ultimately we want non-logical models or irrational program behavior to be considered an exception. So the exception handling strategy flows from Layer 5 of the PADL (Parallel Application Design Layers) and the PBS. It is a fundamental part of the software architecture. User-defined C++ Predicates form the application's logical argument. If one of the assertions or predicates turns out to be false, then the application is irrational at that point. The PBS of an application clearly defines what the possible worlds of an agent or knowledge source will operate within. For every world that is possible for the agent, there is a set of acceptable code that the agent or knowledge source can execute.

As software developers, we produce applications in the fields of medicine, manufacturing, homeland security, transportation, finance, education, scientific research, and all areas of business. We have an ethical and moral responsibility to produce software that is safe, correct, reliable, and fault tolerant. Anything less is malpractice.

This is an excerpt from our book, Professional Multicore Programming: Design and Implementation for C++ Developers.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.