Service-oriented Operating Systems

Processor and network architectures are making rapid progress with more and more cores being integrated into single processors and more and more machines getting connected with increasing bandwidth. Processors become heterogeneous and reconfigurable, thus allowing for dynamic adaptation to specialised needs. In future, thousands of billions of devices may be connected to form a single computing unit.

No current programming model is able to cope with this development, though, as they essentially still follow the classical van Neumann model. Furthermore, complex, non-aligned middlewares and operating systems render distributed applications unnecessarily inefficient. In order to realise efficient programmability of terascale devices by experts and average developers equally, a complete new approach to handling these types of devices across all layers is required:

The S(o)OS project addressed future distributed systems on the level of a holistic operating system architecture by drawing from Service Oriented Architectures and the strength of Grids. This decouples the OS from the underlying resource infrastructure, thus making execution across an almost unlimited number of varying devices possible, independent from the actual hardware.

S(o)OS investigated alternative Operating System Architectures that base on a modular principle, where not only the individual modules may be replaced according to the respective resource specifics, but, more importantly, where also the modules may be distributed according to the executing process’ requirements. The Operating System thus becomes a dynamic service oriented infrastructure in which each executing process may specify the required services which are detected, deployed and adapted on the fly.

Whilst this can obviously increase heterogeneity of execution, it contributes nothing to increase scalability. What is more, the effective requirements for a full application (i.e. a standalone process) towards the Operating System capabilities are closely related to the full OS in the first instance. However, by analysing the specific requirements of the process over execution time, it becomes obvious, that not all the logical parts of one code pose the same requirements toward the Operating System, or in other words that individual segments have only need for specific OS services or modules.

One major key to parallel execution and in particular to resource utilisation consists not only in parallelisation of the code (which, in accordance with Amdahl’s law, is restricted in the first instance), but more importantly in exploitation of concurrency inherent to the code: concurrency is a key factor in all parallel code execution, as it is directly anti-proportional to the code performance, i.e. even though parallelised code can be executed on multiple processors at the same time, the actual efficiency is strongly influenced by the degree of message exchange between these processes – and thus, by their concurrency.

What is more, if two segments are concurrent from one another and do not show indirect time dependencies, they can be executed in parallel, non-regarding their execution order, thus improving resource usage significantly.

S(o)OS examined how code can be segmented in a fashion that allows for concurrent execution over a heterogeneous infrastructure by combining the two approaches above. This principle implicitly supports parallelisation of code in a fashion that reduces the communication overhead. With the information about the code behaviour and dependencies, further optimisation steps can be taken related to the infrastructure’s communication layout, cache and memory limitations, resource specific capabilities and restrictions etc. Depending on the size and complexity of the segments, on-the-fly adaptation steps may furthermore be taken to increase heterogeneity and in particular to improve performance by exploiting the resource features.

The according features feed back to the developer who can exploit the according capabilities to control how hardware is used, respectively how code relates to resources, e.g. by exploiting additional information about dependencies etc. S(o)OS therefore also examines how these capabilities can principally be exposed in a programming language.

Overall, S(o)OS intends to enable even average developers to cope with large, widely distributed infrastructures.

The actual objectives of S(o)OS can therefore be regarded as threefold: (1) to examine alternatives to classical OS architectures with a specific goal to increase scalability, heterogeneity and usability, (2) to evaluate the impact of these architectural choices on the organisation, implementation and execution of the Operating System, and (3) to sketch out and develop alternative / improved algorithms to realise the according OS capabilities.

View S(o)OS results...