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

The Divide-and-Conquer Approach

As they say, there's "more than one way to skin a cat" and developing new languages that explicitly address concurrency is one way forward, but is anathema for developers that have significant investment in legacy (C++, C#, Java) code. The extension of existing languages and/or provision of libraries are alternative approaches, but since they are essentially retrospective, are likely to involve compromise somewhere along the line.

Most would probably agree that algorithmic logic is normally best considered as a set of sequential steps involving conditional logic (e.g., if-then-else). On the other hand, scheduling logic is inherently parallel and is more naturally considered in terms of branching and merging metaphors.

Scheduling and processing are clearly different, and separable concerns; and so an alternative way forward is to allow developers to specifically describe their application's concurrency in terms of its connectivity and dependency, but leave algorithmic and business logic in its current sequential form. This means that existing applications can be largely unaffected by migration to multi-core and most developers can continue to work in a familiar sequential environment using familiar tools and languages.

Equally importantly, concurrency needs to be expressed in a manner that does not make any assumptions about the target platform; number of cores, number of machines, memory distribution, and so on. This means that programmers need to be presented with a simple and intuitive "idealized platform." Mapping functionality to target hardware therefore needs to be another separate stage that should not involve or concern application developers.

Visual Concurrency

Blueprint uses a specialized visual programming paradigm to deal with concurrency aspects. This allows descriptions to include branching and merging information in a way that textual equivalents alone do not readily support. In the concurrency domain, statement "order" is replaced by "connectivity," but the algorithmic/business domain remains sequential and is decoupled from its scheduling; see Figure 2.

Figure 2

Conventional text programs derive much of their "meaning" through precise statement ordering, whereas an electronic circuit diagram derives equivalent meaning through its connectivity; this means that the eye can scan circuits in many different orders and still derive exactly the same meaning.

The obvious point here is that connectivity can branch and merge and is therefore an ideal medium for describing concurrency. It is no coincidence therefore that electronic circuitry is usually presented visually, whilst ASIC algorithmic programming (implicitly parallel) is more likely to involve textual descriptions (e.g., VHDL). So arguably, it is the nature of the logic, rather than the nature of the physical hardware, that determines the most intuitive programming approach; and the arrival of multi-core should not be allowed to drastically change the way that developers think.

It is necessary to find a way to map the traditional OO model to code; and to do this it is also necessary to abstract the platform, capture the application's scheduling constraints, and use a new generation of translators to perform the "heavy lifting" required to take OO's high-level concepts, and generate the low-level synchronization code that implements it.

The Blueprint Toolchain

The first step to providing developers with OO's intuitive and widely accepted concurrent programming abstraction is to create an "idealized" environment for concurrent applications to execute within. The second step is to provide a series of independent (orthogonal) descriptions that take the high-level OO platform independent abstraction, all the way through to the deployment of an arbitrarily runtime-scalable set of executables. This six-part series of articles will describe each of these steps, and where relevant, reference early adopter projects like the UK's Surface Ship Torpedo Defense (SSTD) system as proof of concept.

As Figure 3 illustrates, Blueprint separates the mapping of high-level program logic to physical executables into four independent stages:

Figure 3

  1. The first stage is to develop an application for the idealized Single Virtual Process platform. In most cases it is possible to develop and debug this as a single process on a standard laptop or desktop (specialized I/O devices can be modeled using Blueprint devices). This involves two distinct components -- a textual algorithmic/business logic description, and a visual concurrency constraint description.

  2. The second (independent) stage is to use the accretion editor to map program logic to one or more distinct "processes."

  3. The third stage is to use the colony editor to identify those processes that are to be "slaved". The translator can then build each required process type.

  4. Finally, the task manager is used to allocate instances of each process type to appropriate machines in the available network.

The latter three stages are relatively lightweight and do not involve modifying the application itself. There is no limit to the number of accretions, colonies, or network configurations that can be applied to a given logical Blueprint application. If the application itself is correctly written (no undetected race conditions) then each mapping will usually execute repeatedly (albeit at different speeds), allowing most debugging to be undertaken with a simple single process (and often single threaded) build.

Next Time

In the next installment of this six-part article, we examine the issues involved in separating an application's scheduling logic from its algorithmic/business logic by providing examples.

For More Information

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.