Hardware Support for the Distributed Operating System of the Heidelberg Polyp Processor

Abstract

A multiprocessor consisting of independent processing elements with local memory and local system and application software is a special case of a distributed computer system (DCS). This paper describes such a system, the Heidelberg Polyp polyprocessor [1], its distributed operating system (DOS), and hardware support for distributed resource sharing. Current versions use 30 clusters with one or a few 32 bit microprocessors each [2,3]. Depending on the configuration, clusters may be general purpose or specialized servers. Clusters offering the same server functions can be grouped into pools of identical resources. Clusters using specialized hardware set up static pools. General purpose processor clusters can be specialized by software and can be assigned to pools dynamically. Hardware support is provided for handling pools independent of their sizes. Thus, adding new members to pools for speed up or shut-down of faulty members can be done software transparently. All processing clusters are interconnected by multiple buses for data transfers and interrupts. The system is managed decentrally by a DOS. A copy of this DOS is stored locally in each cluster. DOS requests may be executed in parallel and operate on common, but distributed system tables. The basic function of the DOS is to assign tasks with certain requirements to clusters supplying these functions and to establish communication between them. Some of the DOS functions may be time critical for certain applications. For that, hardware support is offered, e.g. for setting up an optimal dynamic load distribution within a heterogeneous DCS [4]. Pool-size independent system management as well as hardware scheduling is done via two resource sharing interconnection networks (RSIN) [5]. One of them, the Polybus system [6] allows to address pools as a whole and to request random selection of a member by hardware. The other RSIN, the Syncbus, allows to distribute priority queues of waiting tasks and uses a nonempty queue status as a distributed programmed interrupt to a certain pool. Application of boths RSINs is discussed in detail.