Frequently used Terms and Concepts
Throughout the Blueprint documentation, there are references to CLIP, Blueprint, CDL, CORE and other related terms. This section explains what these terms mean, and how they are related. For a more comprehensive list of terms see the Glossary.
Connective Logic
A high level Object-Oriented programming paradigm that specifically addresses concurrent/parallel applications.
CLIP
The Connective Logic Infrastructure Programming system (CLIP) refers to the technology itself. This includes the Blueprint toolset, the CORE runtime, and the CDL Visual Programming Language (VPL). If you are a first time user then we would recommend reading the Connective Logic paper which gives a high level introduction to the whole approach. If you would like a more technical description of how the technology works under the hood then the Holographic Processing article provides an overview of the CORE runtime. An understanding of the internals is not essential, but it will probably be useful to those developers that need optimal performance from their applications.
CDL
The Concurrent Description Language (CDL) is the translatable Visual Programming Language supported by the Blueprint development system's editors and translators. The translator generated code is compiled and linked with the CORE runtime. The Connective Logic paper gives a high level introduction, as do the Video Tutorials. For more detailed information, refer to the Nodal Objects and Connection Objects sections of the programmer's reference.
Blueprint
Blueprint refers to the IDE hosted development system. This includes the graphical editors, the translator, browsers and so on. This allows the development of hybrid applications, in the same way that GUI designers do; but in this case the top level is CDL, a concurrent Visual Programming Language which orchestrates the parallel execution of the underlying conventional sequential processing/business logic. We would recommend new users to familiarize themselves with the tutorial videos on the Connective Logic web site (see Video Tutorials) before working through this help documentation.
CORE
The Concurrent Object Runtime Environment (CORE) is a distributed runtime that provides the application with a consistent platform independent environment. The runtime itself has been ported to a number of operating system's and platforms (see web-site for details) but more importantly, the network topology and machine details are also transparent. CORE provides the application with a number of services and these are detailed in the Runtime System Calls and Services sections of the programmer's guide. Again, the Holographic Processing article provides an overview of the runtime internals for those that are interested, but it is not essential reading.
Infrastructure Logic
A fundamental feature of Blueprint is its orthogonal programming model which factorizes application logic into two distinct domains; infrastructure and processing. The infrastructure component (a superset of coordination) can be thought of as a concurrent schedule with a number of responsibilities;
It must ensure that the processing functions are executed in a legitimate order (calculation dependencies must be observed); data must be delivered to the right place at the right time, and in particular component interfaces must be prototyped and validated (data types, quality of service etc); automatic (transient) data must persist until it is no longer referenced, and then its space returned for re-allocation; these objectives must be achieved in a thread-safe manner (data races, deadlocks etc must be avoided).
Another way to think of this partition is that processing determines 'what' is executed whilst infrastructure determines 'how' it is executed. In practice, this means that CDL replaces thread synchronization, messaging and other ad hoc interfacing with a single unified paradigm, referred to as connective logic, which explicitly addresses timing issues such as deadlocks, race conditions and priority inversions in a localized repeatable manner.
This means coding can be specialized and naturally leads to a hybridized language approach where processing logic is expressed textually (C++, C#, Java etc), and infrastructure logic can be expressed graphically (CDL). This is similar to digital electronics descriptions where some aspects of the logic are most easily expressed in text (e.g. VHDL), and others in schematics (circuitry). In fact CDL diagrams are usually referred to as circuits.
Autonomous and Distributed
Blueprint supports two build categories. Applications that run as a single process (albeit across many processing cores), are referred to as 'autonomous' applications. Applications that comprise more than one executing process are referred to as 'distributed' applications. Distributed applications have a few restrictions that arise from the fact that pointers from one process are seldom valid when sent to an adjacent process. Blueprint provides a number of mechanisms for dealing with these issues.
In many, if not most cases, applications will only be required to run on a single machine, and so it is tempting to assume that these issues do not apply. However, it is unlikely that next generation multi-core processors will be able to provide the symmetric shared memory model that is assumed by today's multi-core applications and if this is likely to be an issue, then the prudent way forward might be ensure that your Blueprint application will run across a network. If it does, then it will probably migrate to the anticipated distributed memory multi-processors of the future, without any need to change code. See Migration to Blueprint.
Nodal Objects and Connection Objects
CDL diagrams include two types of object. Nodal objects, and Connection objects. Broadly speaking, the analogy with electronics would be components and wires. Both object categories have over-rideable attributes. Nodal objects publish (provide) and/or subscribe-to (consume) events that are propagated along connections.
Active, Executable, and Passive Nodal Objects
An Active object is one that owns sequentially executing code, and CDL supports three active objects. Firstly, CDL Threads provide a portable means of exploiting standard operating system threads. In this case control persists in the user code, and in practice CDL threads are only likely to be used for external I/O where blocking occurs outside of the CORE runtime scheduler. Most code is executed in Methods which are propelled by system managed worker threads. GUI code is generally executed by Call-Back functions that execute in the main thread.
Executable objects such as devices and interface objects are executed from the sequential code that is hosted by their accessing threads, methods and call-backs.
Passive objects which include stores, semaphores and event propagators, are managed by user threads, worker threads, and in some cases the main thread. So whilst you could think of collectors, multiplexors, distributors etc as executing asynchronously, in reality it is not usually possible to determine the specific thread that will actually provide their propulsion. In the case of autonomous builds the number of threads is usually equal to the number of cores, multiplied by the number of different utilized method priorities, plus the main thread, plus each user created thread element.
Automatic, Trigger, Manual, Reference and Notification Connections
CDL supports a number of distinct types of connections. Connections between passive objects are referred to as Automatic and are managed automatically by the runtime. Trigger connections are the means by which methods and call-backs are triggered to execute and are also managed by the runtime. Manual connections are provided as a means for active objects to manage passive objects under program control, and are mandatory for threads. Reference connections are not objects as such, but allow access to devices and circuit connection points. Notifications are generated when objects change state. The current release of the runtime only supports one class of notification. See AST Update Notification.
Data objects and Records
Transient Store buffers, Arbitrated Store buffers, Active Object workspace, Circuit workspace, and Method state, all have associated data objects. In all cases, data objects have two components. The first of these is the 'data' component itself which is referenced and managed by the second 'reference' component. The data component can contain native pointers and references but these will not be valid if data objects are moved between machines (only an issue for distributed applications), and are unlikely to be valid in asymmetric memory environments. They can be used however to reference objects within the data component but will need to be 're-linked' each time their owning store is opened for read. This approach is often used to implement variable sized multi-dimensional arrays that require time critical access. The reference component is referred to as a 'record' and is actually just a reference and status word with a number of member functions. For more detail see Data Objects.
Mappings; Circuitry, Processes, Colonies and Executables
At its highest level of abstraction, the standard OO view of the world makes no assumptions about the eventual mapping of functionality to processes. It does not assume how invocations will be implemented (reference or message passing); and this is the level that most engineers find convenient and intuitive. Blueprint operates at this level of abstraction, and mappings of functionality to processes etc, are made at a later 'just-in-time' stage. In particular the co-locality of objects, and hence their communication paradigm, is deferred until runtime and is not an issue for the developer.
Click to enlarge