Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink
	TABLE OF CONTENTS Introduction The Divide-and-Conquer Approach

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.

1 Introduction | 2 The Divide-and-Conquer Approach Next Page

RELATED ARTICLES This Week's Developer Reading List This Week's Multicore Reading List A Structured, Unified Approach to Multi-Core and Many-Core Computing -- with Applications Logging In C++ : Part 2 OutSystems Updates Agile Platform		TOP 5 ARTICLES No Top Articles.