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.
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:
- 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.
- The second (independent) stage is to use the accretion editor to map program logic to one or more distinct "processes."
- 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.
- 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
- Multi-Core OO: Part 1
- Multi-Core OO: Part 2
- Multi-Core OO: Part 3
- Multi-Core OO: Part 4
- Multi-Core OO: Part 5
