Object-oriented model of threading

Threading mechanism is not a function of a programming language. Therefore, a system programming language like C++ should only provide library support for developing concurrent system software. Third party libraries can also provide multi-platform synchronization mechanisms for the set of platforms that are close enough in system calls and related facilities.

The abstraction described here is only possible due to the fact that the Z47 processor supports its own mechanism for threading. This capability of the Z47 processor is part of its design to support a universal abstract language for developing application software. In particular, Z++ executables remain multi-threaded even on platforms that do not provide any mechanism for concurrence.

The design of linguistic constructs for expressing multi-threaded solutions should not produce a reflection of the capabilities of the underlying platform. The purpose of designing an abstract language is to map the low level computational facilities to expressive linguistic forms. The mapping, however, should preserve coherence to the rest of the language in order to reduce the causes of producing defective software.

The language Z++ presents two models for expressing concurrent problems: an object-oriented model and a functional model. The functional model uses a simple and intuitive synchronization mechanism while the abstraction of the object-oriented model hides all the details.

The object-oriented model is identical to the class construct except for the term “task” replacing the keyword “class”. The two constructs of class and task are identical in all respects, including the following.

1. Tasks can be derived via multiple-inheritance.
2. Tasks can be members of other tasks.
3. Template tasks work just like class templates.
4. A task can have invariants.
5. Task methods can be constrained (contracts).
6. A task can represent a (remote or local) module.

The first two items demonstrate how Z++ model reduces the process of solving a multi-threaded problem to a direct statement of that problem as opposed to engaging in detailed encoding. The remaining items indicate the orthogonal design of Z++. The last item on the list, in conjunction with modular capabilities of Z++ provides an entirely new wave in component-oriented development.

At elaboration of a task instance, first a new thread is created and then the instance is constructed in this new thread. At end of scope, the task instance is destroyed and then its thread is terminated. Beyond this, the only difference between the type-constructors class and task is in the behavior of their instances, with regard to public methods.

Calls to public methods of a task are queued by an instance of a task. Once the task thread receives its slice of execution, the instance will service the requests waiting in its queue. All of this is of course transparent at language level and entails no maintenance.

The functional model is just as intuitive as the object-oriented model described here. However, an illustrative code example is helpful with regards to the functional model. The article Z++ Threads provides simple coding examples.