An Object Oriented Software Development Language for Concurrency

The Concurrent class Description Language (CDL) provides a software development language that specifically addresses the description of concurrently executable classes (referred to as ‘circuits’). The CDL software development language allows developers to produce concurrent (multi-threaded and/or multi-process) applications without the need to become involved in low level threading and/or messaging. As well as enabling the development of regular (data-parallel programs) CDL specifically addresses the more general and difficult case of irregular concurrency.

Why Do We Need Concurrent Software?

Concurrent programming is an issue for multi-threaded applications, or in the more general case, distributed applications (comprising two or more processes which may themselves be multi-threaded). Typically, multiple threads may arise because of the need to address complex I/O (message handling etc), or, more likely, asynchronous execution (GUI offload, stream-processing or web-service calls). Multiple processes on the other hand, may be required to isolate sub-systems or perhaps to physically distribute functionality.

Concurrent programming is also required for applications that wish to recruit more than one CPU in order to improve performance. This could be anything from a weather prediction model, to a desktop application that simply needs a ‘snappy’ GUI interface. It is chiefly because of performance issues, that the arrival of multi-core processors is expected to take concurrent programming from a relatively niche activity to a mainstream occupation.

What is the Problem With Existing Solutions?

Whilst the subset of applications that have ‘data-parallel’ architecture have been addressed by OpenMP, MPI, stream-programming and many other technologies and techniques, this still leaves the most general case of irregular concurrency largely outstanding. This is usually the case if there are no loops to unroll, or if function execution time is asymmetric or unpredictable (so the load cannot therefore be easily balanced). The vast majority of software is ‘irregular’.

The problem is that with the exception of a few well behaved ‘data-parallel’ problems (for which there are many solutions), concurrent programming is very difficult. Most believe that this arises because of the need for a high level alternative to low level issues like threads, locks and messages. Another reason is that traditional treatments are ‘dispersed’ across multiple files making their logic difficult to follow. But perhaps worst of all, they lack composability (concurrently executing objects are not easily combined).

“Not only are today’s languages and tools inadequate to transform applications into parallel programs, but also it is difficult to find parallelism in mainstream applications, and—worst of all—concurrency requires programmers to think in a way humans find difficult.” - Herb Sutter, Microsoft Software Architect & chair of the ISO C++ standards committee, January 2005

What is the CDL Software Development Language?

CDL is best thought of as a software development language extension, some might call it a co-ordination language (although CDL is very different from typical co-ordination languages). Its principal goal is to replace threading within processes; and messaging between processes; with the unifying concept of concurrent classes. CDL therefore isolates the activity of class description in exactly the same way that UML or Visual Studio’s class designer do.

The CDL software development language supports fundamental O-O concepts such as public and private member data/functions, aggregation, inheritance, and encapsulation; but in this case the semantics are extended to allow the developer to specify an object’s concurrent behavior (synchronization, execution sequence dependencies, exclusion, re-entrancy etc). CDL is arbitrarily composable and circuits can therefore be nested and/or otherwise aggregated.

Circuits are therefore equivalent to classes and translation between the two is largely automatable. If sequential code is translated to its concurrent equivalent humans are required to identify granularity etc.; most sequential code has latent irregular concurrency.

How is the CDL Software Development Language Used?

As with class designers (and indeed GUI designers) CDL forms part of a hybridized programming approach that separates generated files (circuitry is translated to standard source code) from user entered code (processing, I/O, data access etc). Once translated, CDL typically accounts for between 20 and 40% of executable application code.

CDL is language neutral (translatable to C++, JAVA etc) and therefore interoperates with standard code. It can also be freely mixed with web-service, stream-programming, sockets and any other standard technology. CDL methods can call non-CDL code, and vice-versa. In fact migration to CDL is most easily performed incrementally (class by class).

Since threading and messaging logic is replaced by the CDL software development language, the residual source text is sequential. This leaves most engineers in a familiar programming environment, re-uses legacy code, and limits the need for engineers to become involved in concurrency at any level.

Data parallel applications are primarily developed through the notion of ‘tensor’ (multi-dimensional) circuitry, whilst irregular concurrency is implemented through the notion of ‘event operators’ (arbitrarily connectable implicit object primitives; these include collectors, multiplexors and distributors). Most applications involve both mechanisms.

CDL circuitry doesn’t make any assumptions about target topology and the mapping of functionality to executable processes occurs at translation time. This means applications can be largely developed and maintained as single processes but deployed in any configuration. CDL will execute on SMP, AMP, CMP and arbitrary networks of each. It also has a runtime discovery service and so network configuration need not be assumed either.

Because CDL involves expression of connectivity (and synchronization is factorized) it is possible to perform static analysis for deadlocks, race conditions, priority inversions etc.

Why a Visual Software Development Language?

The CDL software development language can be expressed textually or graphically but almost all early adopters to date have chosen to draw their circuits. There appear to be a number of reasons for this;

• Most developers find concurrent activity far simpler to visualize than verbalize. Apart from anything else, the developer can ‘see’ all of the logic simultaneously (rather than searching through text files).
• Diagrams are language neutral and can be translated to any suitable text language. They do not assume operating systems or platform architecture. This means they are portable to any target that the runtime has been ported to.
• Most engineers that are asked to describe their application’s macroscopic functionality (where concurrency manifests) will head for a white board and draw (rather than write). Schematic class designers are probably popular for the same reason.

How Does The CDL Software Development Language Work?

At runtime, circuitry is transparently translated to distributable state machine arrays which are ‘executed’ by system owned worker threads (one per core per priority by default). This avoids thread proliferation but more importantly, because this is a lightweight operation, allows extremely fine grain load-balanced execution. In fact the system will even load balance over a network and does so preemptively. Because execution is actively scheduled, slave processors can be recruited and/or retired at any stage of the calculation.

What are the Applications for CDL?

Since the CDL software development language provides concurrent equivalents for standard O-O classes its application is potentially generic. That is to say that it could be used to realize the concurrency in any O-O project. In practice however, like any other technology, it is only useful for applications for which it provides some advantage over other solutions and in this case, it is limited to those applications that will benefit from concurrent execution in the first place.

Projects to date have included; high performance digital sonar, distributed war games, finite difference time domain problems, software radio, a thermal line printer, radar simulation, a redundant server baggage handler, surveillance systems, a variable fidelity graphics demonstrator, Voice over IP and CLiP’s own desktop development toolset.