6. Kapitel

        6.      Die Supersprache

"Ich? Nein. Ich hatte einen Kurs in Extended-Modula-2112."

"Ah. Die Konkurrenz." Miesner lächelt nicht einmal bei der Bemerkung, und ich weiß nicht, wie sie gemeint ist. Ich weiß wohl, daß es zwischen den Anwendern verschiedenen Programmiersprachen so etwas wie Glaubenskämpfe gibt, aber worum es da geht, das weiß ich nicht.

"Das Runtime-System ist die Sammlung aller vordefinierten Routinen, die ein Programm mal brauchen könnte. Das ist in Ihrem Modula genauso. Wenn Sie nur ein Wort auf den Bildschirm schreiben, dann rufen Sie in Wirklichkeit diese vorbereiteten Prozeduren auf, die das für sie erledigen. Wie die Bildschirme mit dem Rechner zusammengeschaltet sind, das brauchen Sie alles nicht mehr zu wissen. Genauso ist es mit der Garbage-Collection. Der Anwendungsprogrammierer soll sich nicht auch noch darum kümmern müssen. Wenn er sich aber darum nicht kümmern MUSS, dann bedeutet das aber auch, daß er sich unter Umständen auch nicht darum kümmern KANN."

Ich mag den Herrn Miesner. Manche Fachleute kommen einem so hochgestochen, daß man wie ein Dummkopf dasteht, der nicht begreift, wovon die Rede ist. Der Miesner ist aber aus anderem Holz. 'Sie haben Ihren Job gelernt, und ich den meinen. Und ich erkläre Ihnen jetzt aus meinem Job etwas so klar wie möglich, weil Sie das jetzt verstehen müssen und auch verstehen können.' Das ist ein Stil. Nicht so etwas wie 'Wenn Sie nicht verstehen, wovon die Rede ist, dann stören Sie wenigstens nicht den Unterricht.' So etwa würde die Straub reagieren. Ich schiele ihr nach. Sie steht in einiger Entfernung und hört uns zu. Ihre Art, einem so ab und zu mal eine gepflegt reinzurempeln und ganz allgemein auf dem Selbstbewußtsein der Mitarbeiter herumzutrampeln, kommt im Moment noch nicht zum Zuge, weil sie den Miesner nicht einschätzen kann und weil sie auch noch nicht genau weiß, was eigentlich vorgefallen ist. Das wiederum kann sie nicht zugeben.

"Wenn Sie Modula können," fährt Miesner fort, "dann wissen Sie, daß es so etwas gibt wie Programmteile, die parallel laufen können. In Ada gibt es das auch. Da nennt man sie Tasks, nicht Co-routinen wie in Modula. Das ist aber nur eine Namensakrobatik. Im Prinzip ist beides dasselbe.

"Wie ich schon erwähnt habe, besteht das Steuersystem der Stadt aus einer ganzen Reihe von solchen Tasks. Und praktisch alle davon müssen mit den numerischen Modellen der Stadt rechnen. Einige davon dürfen die numerischen Modelle sogar verändern. Wenn das geschieht, dann darf nur eine einzige Task ein bestimmtes Modell verändern, und solange diese Veränderung abläuft, dürfen andere Tasks dieses Modell nicht einmal ansehen. Denn sonst könnte es ja vorkommen, daß erst ein Teil des Modells verändert worden ist, dann liest irgendeine andere Task etwas aus dem Modell, und erst danach wird die Änderung des Modells vervollständigt. Die Task, die vor, während und nach dieser Änderung Daten aus diesem Modell gelesen hat, hat deshalb Daten bekommen, die überhaupt nicht zueinander passen.

"Ein Beispiel. Stellen Sie sich vor, daß ein neues Stadtmodell aus einem alten erzeugt wird, indem die - numerisch dargestellte - Stadt in die Länge gezogen wird. Das würde zum Beispiel passieren, wenn jemand auf die Idee käme, nur die vorderen Antriebsmaschinen anzulassen und dadurch eine mechanische Streckbeanspruchung zu erzeugen.

"Die Task, die aus einem solchen Modell liest, könnte etwa geometrische Daten der rechten Stadtseite und der linken Stadtseite zu verschiedenen Zeiten lesen. Wenn nur eine der beiden Seiten der Stadt numerisch gedehnt worden ist, und die andere noch nicht, dann kommt die lesende Task zu der Ansicht, daß die Stadt gebogen worden ist. Je nachdem, was diese Task zu tun hat, kann das zu ganz unangemessenen Reaktionen führen!"

Mir kam das sehr einleuchtend vor. Ich nicke. Aus den Augenwinkeln sehe ich, daß die Straub auch nickt, bemüht, das schnell genug zu tun, so daß es nicht so aussehen kann, als nicke Sie nur deshalb, weil ich es tue, oder weil es der richtige Zeitpunkt zum Nicken zu sein scheint.

"Es gibt ein paar Tricks, um zu verhindern, daß der fast zeitgleiche schreibende und lesende Zugriff verschiedener Tasks auf Daten zu einem Chaos führt. In der ersten Version der Sprache Ada gab es zum Beispiel das 'pragma SHARED', das mit den Namen von Variablen als Argument geschrieben werden konnte. In der nächsten Version der Sprache gab es dann schon die 'protected types'. Mit beiden Sprachkonstrukten konnte sichergestellt werden, daß Zugriffe auf gemeinsame Daten sich nicht gegenseitig in die Quere kamen. Wenn eine Task eine Variable schrieb, dann hatte die nächste Task, die in diese Variable schrieb oder aus ihr las, eben zu warten, bis die vorherige Task mit ihrem Zugriff auf die Variable fertig war. Auf diese Weise wurden zusätzliche Synchronisationspunkte geschaffen, zusätzlich zu den entry-calls."

"Entry-calls?" frage ich.

Ein Anflug von schiefem Grinsen legt sich über Miesner's Gesicht, wenn auch nur kurz. Das übliche Problem des Fachmannes: Zuhörer kommen nicht immer mit. Dann muß man die Zuhörer aufklären, ohne sie mit einem Hinweis auf ihren unvollkommenen Wissensstand vor den Kopf zu stoßen. Er kann das - in höflichem Tonfall fährt er fort:

"Entries sind gewissermaßen Prozeduraufrufe, die eine Task einer anderen zur Verfügung stellt. Ada-Fanatiker würden diese Erklärung für ungenau halten, aber es sagt das wesentliche. Bei einem Entry-call muß eine Task versuchen, einen Entry einer anderen Task aufzurufen, und diese andere Task muß auch tatsächlich bereit sein, diesen Entry-call zu bedienen, das heißt, den Code abzuarbeiten, der diesem Entry zugeordnet ist. Deshalb ist auch das ein Synchronisationsmittel, und diese Art der Kommunikation bezeichnet man als synchrone Task-Kommunikation."

"Aha. Nicht-Synchrone Task-Kommunikation hieße also, daß eine Task von einer anderen was will, diesen Wunsch mit einem Entry-Call absetzt und dann weitermacht, die andere Task sich aber durchaus Zeit lassen kann, bis sie dem Entry-call entspricht?" vermute ich, die aufmerksame Schülerin spielend. Einem guten Dozenten muß man ab und zu zeigen, daß man mitdenkt.

"Asynchrone Task-Kommunikation. Ja, genau das ist es. Man konnte in dem alten Ada auch schon asynchrone Task-Kommunikation programmieren. Es war aber ein bißchen aufwendig. Man brauchte dazu im allgemeinen eine eigene Task als Mittler der asynchronen Kommunikation. Diese Task hatte dann nichts anderes zu tun als von anderen Tasks Botschaften entgegenzunehmen und bei Gelegenheit weiterzuleiten. Eine Briefträgertask, gewissermaßen.

"Aber wir wollen nicht abschweifen. Die späteren Versionen von Ada hatten mehr Möglichkeiten der Intertaskkommunikation. Und auch die Kommunikation über gemeinsame Variablen, die durch das 'pragma SHARED' diszipliniert worden waren, wurde erweitert.

"Dieses allererste Pragma galt zum Beispiel nur für skalare Variablen, also solche, die in einem Speicherwort abgelegt werden konnten - Ganzzahl-Variablen, Adressen, Gleitpunktzahlen. Das lag daran, daß die Hardware bei solchen Datenzugriffen die Unteilbarkeit der Speicheroperation im allgemeinen sowieso schon garantierte. Es war leicht zu implementieren. Es stellte sich aber heraus, daß, wenn man schon ein 'pragma SHARED' hat, dasselbe eigentlich potentiell für jeden Datentyp benutzt werden kann. Genau diese Spracherweiterung wurde in den nächsten Versionen von Ada mit aufgenommen. Die Compilerbauer hatten einiges zu tun - das Runtime-System muß auf die Einhaltung der korrekten Reihenfolge der Speicherzugriffe aufpassen.

"Aber Programmierer sind nie zufrieden. In Analogie zu Dateizugriffen wollten sie einen Mechanismus haben, der zum Beispiel den gleichzeitigen Mehrfach-Lesezugriff verschiedener Tasks auf eine Datenstruktur erlaubt. Dann wollten sie diese Optionen nicht nur als Pragma haben, die ein Compiler nach Belieben zurückweisen kann, sondern als obligaten Sprachbestandteil. All das ist in die verschiedenen, aufeinanderfolgenden Versionen der Sprache Ada aufgenommen worden. Ohne diese ständigen Adaptionen an die Erfordernisse der Anwenderprogrammiererprobleme hätte sich Ada auch kaum über mehr als ein Jahrhundert als primäre Programmiersprache gehalten."

"Moment mal," unterbricht Rodrigo, "Modula ist aber auch schon älter als ein Jahrhundert!"

"Gerade wollte ich es sagen!" stimme ich zu.

"Ja," sagt Miesner, "Für Ausbildungszwecke! Aber wer schreibt denn heute noch Anwendungen in Modula? Ernsthafte Anwendungen? Und wo sind die anderen Sprachen, die schon im zwanzigsten Jahrhundert definiert worden sind? COBOL? FORTRAN? PASCAL? RPG? PL1? APL? OCCAM? SMALLTALK? LISP? C?, C++? EIFEL? CORAL? JOVIAL? SIMULA?"

"BASIC!" ruft die Straub dazwischen. Wir können unseren Triumph kaum verbergen. Miesner genießt die Rache kalt:

"Aber ich bitte Sie! BASIC ist ein Spielzeug! Sie nehmen aus allen anderen Sprachen dies und jenes, und es ist immer noch möglich, in BASIC mit minimalen oder gar keinen Einsichten über die Natur des Problems ir-gend-et-was zum Laufen zu bringen. Aber erwachsene Leute benutzen doch kein BASIC! BASIC ist für Software-Ingenieure etwa so nützlich wie Zucker für die Zähne! Eine Einstiegsdroge in die Kunst des Programmierens, neigt dazu, unwartbare Programmruinen zu hinterlassen."

Es geht einem richtig warm herunter, zu sehen, wie die Straub rot wird. Wir haben aber nicht die Zeit, persönliche Schläge abzutauschen. Miesner erinnert uns selbst daran.

"Worauf ich hinaus will ist, daß wir bei der Implementation des Zugriffes auf die gemeinsamen numerischen Modelle der Stadt verschiedene Methoden benutzt haben. Das 'pragma SHARED' findet man dort genauso wie die 'OPEN_WRITE' und 'CLOSE_WRITE' Anweisungen, die definierte Strategievorgaben des Zugriffes auf bestimmte Variablen für das Runtime-System vorgeben. Das sind Sprachelemente aus verschiedenen Generationen von Ada. Leider sind alte Sprachelemente in Ada, die durch neu hinzugefügte obsolet gemacht wurden, nicht aus der Sprache entfernt worden, weil man ja immer auf die Portierung von in älteren Versionen einer Programmiersprache geschriebenen Anwenderprogrammsystemen Rücksicht nehmen muß. Damit handelt man sich ein, daß eigentlich für manche Dinge zuviele Sprachmöglichkeiten offenstehen. Diese werden dann auch nebeneinander verwendet. Das kann man in der Praxis gar nicht vermeiden.

"Zurück zu unserem System hier im Stadtcomputer. Es sei nicht verschwiegen, daß da noch ganz anderer Pfusch passiert ist. Das ist in einem großen Software-Projekt unvermeidlich. Wir haben es erst später herausgefunden, als das System schon längst im Einsatz war und offenbar zufriedenstellend funktionierte. Das heißt, man hätte die Reparatur nicht mehr ohne immense Kosten bewerkstelligen können. Da stand auch die Reputation der GENERAL CRAFTS auf dem Spiel. So erhielten wir von unserem Management Schweigegebot. Dieses werde ich jetzt brechen.

Zurück zu meiner Hauptseite

Sie sind Leserin dieser Seite Nummer

This page hosted by Get your own Free Home Page