Dual objects—an object model for distributed system programming

When parallel processing became popular at the end of the eighties, it became evident that common operating systems were not able to deliver the pure performance of parallel hardware to parallel applications. Much processing power was wasted with complex system call mechanisms and sometimes vast resource consumptions of the operating system itself. Even micro-kernel based systems were often too slow, because these also relied on computing power consuming concepts like address space separation or virtual memory systems. Nevertheless, some applications required exactly those functionalities that others denied for performance reasons. Since this contradiction can hardly be solved within a single operating system, the PEACE operating system family[10] was developed at GMD-FIRST. The most simple family members were represented as highly efficient runtime libraries while the most complex members can be regarded as full fledged micro-kernel based operating systems. Family based systems can be implemented conveniently by means of object oriented programming paradigms. Thus the PEACE operating system family has entirely been implemented in C++. Operating system services are implemented as classes and users can extend and specialize these system classes by means of inheritance mechanisms. In theory this scenario is sound and straight forward but in practice the conceptual advantages of object orientation are extremely hard to exploit without suitable object models and language-level support for object-oriented implementation techniques in distributed contexts. When users extend and specialize PEACE classes by means of inheritance mechanisms, class hierarchies need to be extended across address spaces as well as network boundaries and objects can be fragmented across address spaces. This in turn can lead to serious performance bugs caused by frequent remote invocations, when application classes closely interact with their system-level base classes. On the other hand it is obvious that client classes cannot have full access to system-level state information to avoid forgery and ease resource sharing amongst many clients. Implementing system services as fragmented objects[7] like in the SOS system [12] would have supported independence as well as encapsulation of object fragments allocated in different address spaces. Nevertheless we considered that model already too complex for those very lightweight system structures we were aiming at, because