Bill Lamie, CEO von Express Logic

„Echtzeitbetriebssysteme haben eine gute Zukunft“

Seite: 3/4

Firmen zum Thema

„Als erstes schrieb ich das Benutzerhandbuch“

In einem früheren Interview sagten Sie, bei der Entwicklung von ThreadX hätten Sie als erstes das Benutzerhandbuch geschrieben. Wie kamen Sie auf diese Idee?

Reines Genie (lacht). Nun, ich habe das schon einmal so gemacht. Bei Nucleus bin ich genauso vorgegangen. Dafür gibt es zwei Gründe: Ich weiß, dass es sehr lange dauert, die Dokumentation zu schreiben. Also muss man die Softwareentwicklung und die Dokumentation parallel laufen lassen. Das ist der pragmatische Grund.

Es gibt aber auch einen Grund, der die Usability im Blick hat: Wenn man als erstes das Handbuch schreibt, sieht man augenblicklich, welche Kopfschmerzen man dem Anwender bereitet. Man sagt dem Anwender: So musst du das System benutzen – oh, das ist aber schlecht. Also wieder löschen und neu ansetzen – Ja, das ist viel besser.

Und letztendlich dient das Handbuch als Design-Dokument. Und ich würde es jederzeit wieder so machen. Als ich Nucleus entwickelte, habe ich es zum ersten Mal in dieser Reihenfolge gemacht. Ich bin mir zwar nicht sicher, ob der pragmatische Grund für mich damals nicht der wichtigere war. Aber nach Nucleus erkannte ich den Benefit, den man daraus zieht: Das Produkt wird dadurch einfach viel besser benutzbar.

Und andererseits kann man das Handbuch auch als so etwas wie eine Aufgabenliste ansehen.

Ja. Und es hilft noch in einer anderen Hinsicht. Bei ThreadX hatte ich eine ganze Reihe von Ideen, die ich umsetzen wollte. Aber als ich das Handbuch schrieb, half es mir wirklich, klar zu sehen, was ich im ersten Release verwirklichen konnte. Ich konnte das Problem also einschränken. Wenn man sich dazu zwingt, wirklich in die Details dessen einzusteigen, was man gerne abliefern möchte, dann bekommt man die Sache besser in den Griff.

Glauben Sie, dass ThreadX den richtigen Umfang hat? Denn die erste Version von Nucleus (RTX) war, wie Sie einmal sagten, ein wenig zu leichtgewichtig, die zweite (Plus) zu schwergewichtig.

Ja, diesmal hat es genau hingehauen. Ich hatte ja schon vorher andere Echtzeitbetriebssysteme verwendet. Und manche Dinge mochte ich, andere nicht. Ich hatte also bestimmte Vorstellungen, was ich in Nucleus RTX tun wollte. Aber als ich durch das Feedback von Geschäftskunden verstand, wie man die Dinge etwas besser machen konnte, sagte ich mir: Dies und jenes hätte ich tun müssen.

Bevor ich Nucleus Plus entwickelte, machte ich also eine Übersicht von allem, was kommerziell vertrieben wurde und auch von einigen freien Betriebssystemen. Ich schrieb also eine Liste mit allen Features, die sie hatten. Und dann sagte ich: Ich mache das alles. Warum auch nicht?

Das schien anfangs eine gute Idee zu sein. Aber später, als das System ausgeliefert wurde, sah ich, dass wir ein Problem hatten, weil es alle Features an Bord hatte und nur heruntergestrippt werden konnte. Es enthielt auch eine Menge Assembler-Code, denn die Tricks, zu denen ich greifen musste, benötigten mehr Assembler-Code als bei ThreadX. Es war also sehr schwer auf andere Architekturen zu portieren und es war im Vergleich zu ThreadX sehr umfangreich.

Und im Hinblick auf die Performance war Nucleus Plus wegen seiner Input/Output-Architektur relativ langsam. Ich durchlief also eine kurze Phase schlechten Gewissens. Man hat nicht immer die Chance, in den Wettbewerb mit einem alten Produkt zu treten, aber glücklicherweise hatte ich diese Möglichkeit. Und ThreadX hat davon letztlich profitiert.

Zeigt sich hier wieder die alte Pareto-Regel, dass man 80 Prozent der Zeit benötigt, um die letzten 20 Prozent der Arbeit richtig hinzubekommen?

Genau. Man muss sich auch meinen Hintergrund ansehen. Als ich Nucleus RTX schrieb, hatte ich keine Erfahrung im kommerziellen RTOS-Umfeld. Als ich Nucleus Plus schrieb, hatte ich zwei Jahre Erfahrung. Als ich ThreadX entwickelte, waren es schon fünf oder sechs. Und das ist gut. Als ich Nucleus RTX schrieb, konnte ich niemandem sagen, welchen Anwendungsfall es erfüllen sollte. Ich wußte zwar, was ich selbst mochte, aber nicht, was typisch war und was nicht.

Ein interessanter Aspekt von ThreadX ist ja, dass man Prioritäten einigermaßen flexibel vergeben kann. Haben Sie diesen Punkt bei anderen Betriebssystemen vermisst?

Nein, nein. Ich schrieb das Dokument für ThreadX und ich kam zu dem Kapitel, in dem es um das Abschalten oder Ausführen kritischer Bereiche ging. Und dann kam mir ein Gedanke: Normalerweise verteilen sich kritische Bereiche nur auf eine Handvoll von Threads, beileibe nicht auf alle. Und dann fragte ich mich: warum soll man das komplette übrige Scheduling aussperren, wenn man nur einen begrenzten Bereich des Scheduling aussperren kann? Lasst doch einfach die Threads laufen, die an dem kritischen Bereich beteiligt sind, und um die anderen muss man sich nicht kümmern.

Und ich dachte, das ist doch einfach umzusetzen. Die Implementierung ist ein bisschen schwieriger, aber auf dem API-Level ist das ziemlich einfach. Ich dachte einfach, dass es ein einfacher Weg sein könnte, den Benutzern eine gewisse Granularität zu geben. Ich betrachtete es aus der Warte der Responsivität. Man konnte immer noch Responsivität haben, auch wenn sich das System in einem kritischen Bereich befand.

Und jetzt zeigt sich, dass dieser Aspekt noch andere Dinge mit sich bringt. Ich habe nach kurzer Zeit erkannt, dass man damit die Zahl der Context-Switches reduzieren konnte. Andere Forschungen haben gezeigt, dass man das Scheduling mit Hilfe von PT und Prioritäten garantieren konnte. Das System gibt einem Thread zwei Prioritäten: Eine Priorität, während er läuft und eine Priorität, bevor er läuft. Es ergaben sich also noch weitere Vorteile. Der originale Aspekt war aber die Responsivität.

Manche Leute beklagen sich über die Softwarequalität und über die steigende Komplexität der Software. Sie haben Betriebssysteme für harte Aufgaben geschrieben. Was würden Sie zum Thema Softwarequalität sagen?

Ich habe hier nicht viele gute Ratschläge zu bieten. Ich würde aber sagen, dass Einfachheit der Schlüssel ist. Der alte Spruch „Keep it simple“ ist eine gute Praxis. Das ist auch die Nummer 1.

Dann würde ich die Leute ermuntern, als Erstes das Handbuch zu schreiben. Jeder Entwickler sollte seine Aufgabe als ein Produkt sehen. Deshalb sollten sie ein Handbuch dafür schreiben und eine gut definierte Interface-Schicht entwickeln, so dass niemand sieht, was sich hinter dem Interface verbirgt.

Sie sollten ein Include-File einbinden, das das Mapping für die API enthält. Und das ist es. Auf diese Weise kann man den ganzen Spaghetti-Code vermeiden. Und man kann die Produkte wiederverwenden, man hat eine Reihe kleiner Produkte, die man in anderen Applikationen verwenden kann, eben weil sie dokumentiert sind, weil sie ein gut definiertes Interface haben und der Code gut organisiert ist. Ich bevorzuge die komponentenorientierte Methode. Das ist aber alles andere als Raketenwissenschaft, eine Menge Entwickler machen das.

(ID:42239895)