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 ▼

Multi-Core OO: Part 1

John Gross is chief engineer and Jeremy Orme chief architect at Connective Logic Systems. They can be contacted at [email protected] and [email protected], respectively.

This five-part article introduces Blueprint, a technology developed by Connective Logic Systems (where we work) that provides an alternative approach to multi-core development. While Blueprint is interoperable with technologies such as Microsoft's Task Parallel Library (TPL) and Intel's Threaded Building Blocks, it does address some different issues.

At its highest level of abstraction, the traditional OO model is based on autonomously executing objects (actors) that communicate by invoking each others methods. This would appear to be a highly intuitive model for multi-core development. This model makes no assumptions about the target platform, its core count, network topology, or its memory distribution.

The aim of Blueprint technology is to present concurrency and parallelism to developers at this high level of abstraction, to allow familiar top-down decomposition, and then to use translators to generate the necessary harness and low-level synchronization logic. The translators output C++ or C# source, but this is not visible to the developer who can develop their algorithmic/business logic with either language.

To date, the technology has been used for a number of military and commercial projects, including the Australian Warfare Destroyer program and the UK's Surface Ship Torpedo Defense system. In the latter case, about 40% of the deliverable code was generate-able from visual code, and the remaining 60% from sequential C++ source.

The era of multi-core programming has arrived. Many influential commentators have pointed out that concurrent programming requires developers to learn new techniques, different from those adopted for standard sequential programs. In Software and the Concurrency Revolution, Herb Sutter and James Larus describe it this way:

Humans are quickly overwhelmed by concurrency and find it much more difficult to reason about concurrent than sequential code.

However, when humans perform everyday tasks like playing sports or driving cars, they demonstrate an innate ability to deal with complex concurrent situations. Even more ironically, standard object-oriented (OO) models, fundamental to modern software practice, provide an inherently concurrent view of the world that is divorced from its eventual mapping to processes, and hence CPU cores.

Conceptually at least, object-oriented models let asynchronously executing objects communicate with adjacent objects by sending messages to their member functions; and so at its highest level of abstraction object behavior is intrinsically parallel. So why isn't multi-core seen as an enabling technology that facilitates the physical implementation of such a familiar and intuitive logical abstraction?

The answer draws attention to another even more fundamental problem -- the discontinuity that exists between highly abstracted software designs (such as those provided by UML) and the software implementations that manifest programmers' interpretations of these designs. When modeling systems (formally or informally), designers are able to think at a highly intuitive level of abstraction. At this level, most developers are able to visualize concurrency with very little effort. However, implementing these models is another issue altogether.

Pre multi-core/many-core OO has thrived in a single-core, single-machine environment. In this special case, synchronous function calling can replace the asynchronous invocation idealized in the original OO model and the "stack" can take care of data lifetimes in a simple and intuitive manner; see Figure 1.

Figure 1

In the sequential world, mapping an OO model (e.g., parts of a UML design) to a single-threaded executable is a largely automatable task and therefore an ideal candidate for code generation. However, mapping a model to a multi-threaded implementation requires additional synchronization and scheduling logic that is assumed, but not prescribed, by typical models. Mapping to multiple process implementations, which involves the generation of complex messaging logic, only adds to the problem.

The end result of this is that programmers are required to interpret concurrent OO models by hand, make assumptions about the designer's intentions, and then implement significant amounts of difficult code, versions of which may or may not be in step with corresponding design versions.

The industry's response to this has been to provide engineers with new languages, and/or language extensions/libraries that aim to supply the highest levels of concurrency abstraction possible. Not surprisingly, this works fairly well for the special case of "regular" concurrency (e.g., the parallelization of for loops), but fares less well in the more general irregular cases that appear in day-to-day programming.

The reason that most "concurrency specialists" would agree with the sentiments expressed by Herb Sutter and James Larus becomes apparent with a first foray into the implementation of a physically concurrent object model (required to exploit multi-core).

The principal goal of the Blueprint development environment is to present the developer with OO's highly intuitive view of concurrently executing objects, to explicitly allow them to express their synchronization and scheduling logic with a similarly high level of abstraction, and to do so in a manner that makes no assumptions about the target platform's architecture and/or memory topology. Optimally accreting the application's functionality to one or more multi-core machines is a separate (and orthogonal) activity, which means that unless the application is intrinsically platform-locked, the "same" application code will execute across any platform without modification.

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.