GI-NTG Fachtagung Struktur und Betrieb von Rechensystemen

Rechensysteme werden mit erheblicher Unsicherheit entworfen und bewertet. Angesichts der technischen und wirtschaftlichen Bedeutung von Rechensystemen und angesichts der naheliegenden Möglichkeit, Rechensysteme nicht nur zum Objekt, sondern auch zum Werkzeug von Entwurf und Bewertung zu machen, ist dieser Sachverhalt zunächst erstaunlich.

Das Programmsystem COPE (computer performance evaluator) ist ein Instrumentarium zur leistungsgerechten Konfigurierung und Dimensionierung von Rechensystemen aus existenten bzw. projektierten Hardware- oder Software-Komponenten.

Prozeßrechensysteme müssen die Anforderungen, die an sie aus dem zu automatisierenden Prozeß gestellt werden, unter engen zeitlichen Bedingungen, sogenannten Echtzeitbedingungen bearbeiten. Für den Nachweis, daß diese Bedingungen in jedem Betriebszustand sicher eingehalten werden, ist die quantitative Erfassung, d.h. die Messung des dynamischen Verhaltens von Prozeßrechensystemen unabdingbar. Softwaremonitore bewirken hohe Rückwirkungen auf das untersuchte System und sind nicht unabhängig von ihm; Hardwaremonitore erlauben keine Analyse interner Abläufe. Für die ZE 330 der Siemens Systeme 300 – 16 bit wurde deshalb der Ablauf- und Auslastungsmonitor ALAMO 300 als eigenständiger, unabhängiger Beobachtungsrechner realisiert, der über die Techniken des Adressvergleichs und des direkten Zentralspeicherzugriffs mit dem beobachteten System gekoppelt ist. Über Einsatzerfahrungen wird berichtet.

Sowohl der Zugang zur Philosophie der Offenen Systeme als auch ihre Weiterentwicklung werden häufig behindert durch Verständnisschwierigkeiten, die einerseits auf die meist unaufbereitete Form von Originalarbeiten zurückzuführen sind, die andrerseits jedoch auch aus der Jerzeitigen gedanklichen Unabgeklärtheit dieses völlig neuen Wissenschaftsbereiches selbst resultieren. Die Beschreibung der Schichtenstruktur Offener Systeme in den Originalarbeiten gibt üblicherweise Anlaß zu Verständnisschwierigkeiten der ersten Art; fast alle Fragen zum Kontext Offener Systeme bringen Verständnisschwierigkeiten der zweiten Art zutage. Diese Arbeit versucht für diese beiden Fragenkomplexe — Kontext und Schichtenstruktur Offener Systeme — ein sicheres Verständnis zu erzeugen. Sie vermittelt eine Übersicht, weil sie nicht nur die wichtigsten Charakteristika Offener Systeme, sondern auch deren Kontext und die ihnen zugrundeliegenden Philosophien einführend darlegt.

The concept of the virtual network machine conceives the entire distributed hardware of a multicomputer system as a single virtual machine which is capable of executing a system of cooperating processes formulated in a suitable high level language, in this case CONCURRENT PASCAL. All processes communicate by means of MONITORS regardless whether they reside on the same node computer or on different ones. As a consequence of hardware failures remote procedure calls can fail. To handle those errors the use of Brinch Hansen’s guarded regions is proposed.

A model of communicating parallel processes, based on high-level input functions, is introduced. It is called the input tool process model. In this model every process contains an input rule which specifies in an input expression the processes from which it expects input. Depending on the input some action takes place inside the tool process and as a result messages may be sent to the outside world. Because senders and receivers may specify each other with different degrees of identification the model supports very general classes of communication. It is for instance very suitable to utility processes and service routines in operating systems, for communication between system components and between user programs and system components, as well as for user programs communicating with each other. The tool process model is also applicable to nets of processes each running on their own processor. No special primitives for synchronization are needed, because the latter is accomplished implicitly by the input specification.

Echt parallel ablaufende Prozesse in einer modularen, symmetrischen Mehrprozessorumgebung bedürfen einer konfliktfreien wechselseitigen Abstimmung. Durch die Separation und Abspeicherung aller hierfür notwendigen, globalen Synchronisationsvariablen in einem modularen Assoziativspeicher-Koordinatorsystem (ASSKO) können die Prozesse und Betriebsmittel des Mehrprozessor-Systems zu einem effektiven Gesamtwirken gebracht werden. In diesem Beitrag wird der Einsatz dieser Synchronisationsmittel bei der Programmierung von gleichzeitigen, kooperierenden und zueinander asynchron startenden Prozessen angegeben.

This paper focuses on the characteristics of functions in large computing systems that are evaluated in the determination of function placement and selection of implementation media, i.e. software, microcode or hardware. It provides a basic understanding of the tradeoffs of some actual implementations of migrated software functions into microcode and hardware. Further the paper evaluates some future opportunities for significant restructure and function migration in large commercial systems.

Trotz immer schnellerer Zentraleinheiten von Mehrzweckrechnern bleibt der Wunsch nach weiteren Leistungssteigerungen der Rechnersysteme bestehen. Wo er mit Software-Methoden nicht mehr erfüllt werden kann, äußert sich dies häufig in der Entwicklung dedizierter Systeme. Wenn dieser Weg nicht gangbar ist, bietet sich bei mikroprogrammierbaren Prozessoren die Möglichkeit, den Rechner den aktuellen (eventuell wechselnden) Anforderungen anzupassen und dadurch die erstrebten Leistungssteigerungen zu erzielen.

Es werden Probleme der Emulation der Vertikalverarbeitung dargestellt, die als eine Teilaufgabe im Rahmen des EGPA-Mehrrechner-Projektes (Erlangen General Purpose Array) auf mikroprogrammierbaren 32-bit Rechnern AEG 80–60 implementiert wurde. Die Vertikalverarbeitung erlaubt die Formulierung paralleler und assoziativer Sprachelemente innerhalb eines einzigen Maschinenbefehls, wobei die Ausführung auf konventioneller Hardware geschieht, so daß die Einbettung in die vorgegebene Sprachstruktur gegeben ist, der Aufwand für einen Spezialprozessor vermieden wird und die Austauschbarkeit von Prozessoren im Fehlerfalle erhalten bleibt („fail-soft“). Die Eigenschaften der Mikroprogramme zur Emulation der Vertikalverarbeitung (lange Laufzeiten, großer Mikroprogrammspeicherbedarf, Zugriff auf sehr umfangreiche Datenbestände) werfen Probleme bezüglich der Unterbrechbarkeit von Mikroprogrammen, der Übergabe der Parameter, des Zugriffs auf den virtuellen Speicher u.ä. auf, die exemplarisch diskutiert werden und Forderungen an einen emulationsfreundlichen Rechner zulassen.

Rechnerbeschreibungssprachen bilden die Grundlage für den rechnergestützten Entwurf digitaler Systeme. Es handelt sich dabei um formale operative Sprachen, die den Signalverlauf auf den Signalträgern (z.B. Anschlüsse, Register, Speicher) charakterisieren. Sie können sich dabei nicht, wie es bei Programmiersprachen der Fall ist, darauf beschränken, Zustandsänderungen in den Trägern durch Anweisungsfolgen abstrakter Steueranweisungen (Kontrollstrukturen) darzustellen. Sie müssen vielmehr auch die Darstellung solcher Zustandsänderungen als signal- bzw. ereignisgesteuerte Aktivitäten und auf unterster Ebene als Signalfluß unterstützen. Auch müssen neben reinen Signalfolgen auch Signalverläufe in realer Zeit darstellbar sein.

Moderner Hardwareentwurf von digitalen Systemen ist ohne Einsatz von Computern nicht möglich. Es werden hierzu Systeme für die Spezifikation, Simulation und Dokumentation der zu entwickelnden Hardware benötigt. In diesem Beitrag werden die verschiedenen Beschreibungsebenen von Computerhardware und speziell die verschiedenen Formen einer Registertransferbeschreibung dargestellt. Ein ausführlicher Anforderungskatalog zeigt, welche Eigenschaften ein leistungsfähiges Hardwareentwurfssystem für die Registertransferebene besitzen sollte. Mit APL*DS wird ein integriertes Spezifikations- und Simulationssystem vorgestellt, in dem alle geforderten Eigenschaften eines solchen Systems realisiert wurden. Es werden einige Aspekte der Implementierung von APL*DS in der Sprache APL aufgezeigt. Die Syntax und Semantik der wichtigsten Sprachkonstruktionen werden erläutert und ihre Anwendung anhand kleiner Beispiele gezeigt. APL*DS hat sich an verschiedenen Stellen bereits in der Praxis bewährt.

MIMOLA is a language for the optimized design of digital processors, based upon computing resource utilizations for typical programs. It has been used for the design of a well-structured, fast, parallel and microprogrammable processor. Although not larger than a conventional minicomputer, it is about 26 times faster. It proves, that microcode need not be larger than equivalent machinecode. This paper also discusses possible architecture alternatives with low cost/performance ratios.

Die Arbeit befaßt sich mit der geordneten Auflösung von Konfliktsituationen in dynamischen Systemen mithilfe eines Regulationsschemas, das auf dem Begriff des gewichteten Synchronabstandes, einer Invarianzeigenschaft zur Bemessung von Restriktionen im Systemverhalten, beruht. Anhand einer realen Konfliktsituation, wie sie in einem Hochleistungsrechner zwischen mehreren nebenläufig aktiven Kanalprozessen in Bezug auf die Zuteilung des Arbeitsspeicherzugriffs auftritt, wird eine mögliche Anwendung des Regulationsschemas demonstriert.

The paper deals with transparent modelling of information processing systems. Instead of considering hardware and software as the two complementary aspects of the system, the paper considers the physical structure and the informational structure. The informational structure is the abstraction which the human mind associates to the physical structure. In this sense, software also has a physical structure aspect, for example as a magnetic pattern on a disk, and hardware also has an informational structure aspect, for example a group of gates which is interpreted as an adder.

Es wird eine Sprache vorgestellt, die aufbauend auf einem einheitlichen Konzept (zeitbewertete interpretierte Petri Netze) Beschreibungen auf sehr unterschiedlichen Abstraktionsebenen erlaubt. Diese Abstraktionsebenen reichen von der Ebene der Verschaltung von integrierten Bausteinen hin bis zu Warteschlangenmodellen. Auf die Möglichkeit, nebenläufige Prozesse beschreiben zu können, wurde besonders Wert gelegt (CAP steht für Concurrent Algorithmic Programming Language) /RA1/.

In diesem Beitrag wird das Grundkonzept der Sprache, insbesondere die CAP-Netze, erläutert und spezielle Spracheigenschaften von CAP anhand von fünf kleinen Beispielprogrammen vorgestellt. Diese Beispielprogramme sind:

Abschließend wird die bisher implementierte CAP-Software (Compiler, Interpreter/ Simulator, Debugger, Dokumentationsgenerator, optimierender Cross Code Generator, Maschinenmodellgenerator) kurz vorgestellt.

Da das Problem der Deadlockfreiheit in seiner allgemeinen Form nicht lösbar ist, ist die Angabe von nicht allzu schwachen hinreichenden Kriterien zur Vermeidung von Deadlocks besonders wichtig. Dazu kann man einerseits Kriterien angeben, mit deren Hilfe man die Deadlockfreiheit bereits vorhandener Softwaresysteme nachweisen kann. Andererseits kann man aber auch Vorschriften für die schrittweise Erstellung von Systemen angeben, so daß bei Einhaltung dieser Regeln per Definition deadlockfreie Systeme entstehen.

In dieser Arbeit wird ein Kalkül aus zwei Axiomenschemata für primitive deadlockfreie Strukturen und einigen Ableitungsregeln angegeben. Die Ableitbarkeit eines Systems in diesem Kalkül ist hinreichend für die Deadlockfreiheit dieses Systems. Dieses Kalkül stellt ein Werkzeug (tool) zur Konstruktion deadlockfreier Systeme dar.

Da die Vorträge dieser Sitzung sehr verschiedene Teilaspekte von Betriebssystemen behandeln, soll auf Wunsch des Programm-Ausschusses eine Einführung in die Sitzung gegeben werden. Ich möchte hierzu wichtige Grundbegriffe und Grundkonzepte, die bei den Vorträgen vorausgesetzt werden, erläutern.

Monitore wurden nach ihrer Erfindung im Jahre 1973/74 in verschiedenen Forschungsprojekten experimentell erprobt und haben sich dort zur Lösung der gängigen Synchronisationsaufgaben den Semaphoren als deutlich überlegen erwiesen. Der erreichte Erfahrungsstand sollte nun auch die DV-Industrie in die Lage versetzen, dieses neue Konstruktionselement für Systemsoftware einzusetzen.

Ausgehend von der Hoare’schen Definition des Monitors werden alternative Implementierungen vorgestellt und diskutiert.

Varianten des Hoare-Monitors werden insbesondere hinsichtlich der Reduzierung fehlerhafter Programmkonstruktionen sowie ihrer Eignung zur Realisierung bedingter kritischer Abschnitte untersucht.

Vorgestellt und zusammengefaßt werden Konstruktionsprinzipien für ein Realzeit-Betriebssystem, das über einer Klasse struktur-verschiedener Hardware-Systeme portabel sein soll. Portable Betriebssysteme realisieren für unterschiedliche Hardware-Systeme gleiche Benutzerschnittstellen und erhöhen deshalb nicht unwesentlich den Portabilitätsgrad zugehöriger Anwenderprogramme.

Vorgestellt werden darüberhinaus die Funktionen eines Betriebssystemkernes, der typische elementare Betriebssystem-Mechanismen umfaßt. Diese ausgewählten Mechanismen sollten eine minimale und hinreichende Grundlage für die Konstruktion „maßgeschneiderter“, d.h. anwendungsorientierter Betriebssysteme darstellen (dedizierte Betriebssysteme); zugleich sollten sie in einer vergleichsweise frühen Entwicklungsphase Funkionsfähigkeit und praktische Verwendbarkeit des Systems nachweisen.

Das Betriebssystem DAS besitzt eine Domänenstruktur mit unterschiedlich großen Segmenten. Da die Segmente in vielen Fällen zu klein sind, als daß sie auch als Umlagerungseinheiten im virtuellen Speicher fungieren könnten, werden alle Segmente einer Lokalität zu einer Umlagerungseinheit gepackt. Aus welchen Segmenten eine Lokalität sich jeweils zusammensetzt, wird sowohl durch explizite Direktiven des Programms als auch durch Zugriffsfebler und die Entdeckung obsoleter Segmente bestimmt. Die vorliegende Arbeit geht besonders auf das Verhältnis zwischen Domänen und Lokalitäten ein und erläutert den Zusammenhang zwischen Domänenwechsel und Lokalitätsänderung.

Im Gegensatz zu Demand-Paging-Verfahren, bei denen eine nicht im Arbeitsspeicher befindliche Seite genau dann geladen wird, wenn sie referiert wird, können bei Prepaging-Verfahren Seiten, von denen erwartet wird, daß sie in Kürze referiert werden, bereits vor dem Referenzzeitpunkt geladen werden. Im folgenden ist unter Prepaging stets Demand-Prepaging zu verstehen, d. h., Ladevorgänge dürfen nur zu Page-Fault-Zeitpunkten initialisiert werden und die Programmausführung wird erst nach Abschluß aller Ladevorgänge fortgesetzt.