DE102005051101A1

DE102005051101A1 - Verfahren zum Implementieren von Software-Timern und Datenverarbeitungssystem

Info

Publication number: DE102005051101A1
Application number: DE200510051101
Authority: DE
Inventors: Karl-Heinz Krause
Original assignee: Siemens AG
Current assignee: Siemens AG
Priority date: 2005-10-25
Filing date: 2005-10-25
Publication date: 2007-04-26
Also published as: EP1941365A1; WO2007048675A1

Abstract

Bei einem Verfahren zum Implementieren von Software-Timern wird vorgeschlagen, eine Gesamtmenge von Software-Timern in Teilmengen aufzuteilen, wobei jede Teilmenge auf einem jeweils festgelegten Prioritätsniveau bearbeitet wird. Dieser Ansatz einer transparenten Aufteilung der Timer-Gesamtmenge in Timer-Verwaltungscluster, die auf unterschiedlichen Prioritätsebenen bearbeitet werden, ermöglicht, dass auch bei einer großen, ggf. unbekannten Anzahl von verwalteten Timern die garantierten Reaktionszeiten für zeitkritische Aufgaben vorhersagbar klein bleiben.

Description

Die vorliegende Erfindung betrifft zunächst allgemein ein Verfahren zum Implementieren von Software-Timern.
Darüber hinaus betrifft die vorliegende Erfindung ein Verfahren zum Verwalten einer Menge von Software-Timern, wobei alle zu einem gemeinsamen Zeitpunkt ablaufenden Software-Timer in eine Warteschlange mit einem Warteschlangenkopf eingeordnet werden, wobei die Zeitpunkte durch regelmäßige Zeitsignale eines Datenverarbeitungssystems definiert werden, wobei die Warteschlangenköpfe in Abhängigkeit von ihrer Ablaufzeit in einen List-Header einsortiert werden, wobei in einem ersten Bereich des List-Headers mit einer ersten Anzahl N1 von Warteschlangenköpfen jeweils einem von N1 aufeinander folgenden Zeitsignalen ein Warteschlangenkopf der ersten Anzahl von Warteschlangenköpfen zugeordnet wird und wobei in einem zweiten Bereich des List-Headers mit einer zweiten Anzahl N2 von Warteschlangenköpfen jedem Warteschlangenkopf der zweiten Anzahl von Warteschlangenköpfen eine Warteschlange mit Software-Timern zugeordnet wird, deren Ablaufzeiten ein durch den Wert von N1 definiertes Zeitintervall überstreichen.
Des Weiteren betrifft die vorliegende Erfindung ein Datenverarbeitungssystem, das wenigstens eine Speichereinheit, wenigstens eine Prozessoreinheit in Wirkverbindung mit der Speichereinheit, und in der Speichereinheit gespeicherten ersten Programmcode aufweist, wobei durch den gespeicherten ersten Programmcode bei Ausführung in der Prozessoreinheit eine Gesamtmenge von Software-Timern erzeugbar ist.
Zusätzlich betrifft die vorliegende Erfindung auch ein vorstehend beschriebenes Datenverarbeitungssystem mit weiterem in der Speichereinheit gespeicherten Programmcode, durch den bei Ausführung in der Prozessoreinheit ein Programmcode-Mechanismus generierbar ist, der ausgebildet ist zum:

– Einordnen aller zu einem gemeinsamen Zeitpunkt ablaufenden Software-Timer in eine Warteschlange mit einem Warteschlangenkopf, wobei die Zeitpunkte durch regelmäßige Zeitsignale des Datenverarbeitungssystems definiert sind,
– Einsortieren der Warteschlangenköpfe in einen List-Header in Abhängigkeit von ihrer Ablaufzeit,
– in einem ersten Bereich des List-Headers mit einer ersten Anzahl N1 von Warteschlangenköpfen, Zuordnen eines Warteschlangenkopfes der ersten Anzahl von Warteschlangenköpfen zu jeweils einem von N1 aufeinander folgenden Zeitsignalen, und
– Zuordnen jeweils einer Warteschlage mit Software-Timern, deren Ablaufzeiten ein durch den Wert von N1 definiertes Zeitintervall überstreichen, zu Warteschlangenköpfen (Kx) aus einer zweiten Anzahl N2 von Warteschlangenköpfen in einem zweiten Bereich (11.xb) des List-Headers (11.x).

Schließlich betrifft die vorliegende Erfindung ein Computerprogrammprodukt sowie eine Verwendung des erfindungsgemäßen Datenverarbeitungssystems.

Jedes Betriebssystem für eine Datenverarbeitungsanlage, z.B. einen Personal Computer (PC), insbesondere ein Realtime-Betriebssystem für zeitkritische Echtzeit-Anwendungen, z.B. in der Anlagensteuerung, kann sog. Software-Timer verwalten. Dies bedeutet, dass ein Benutzerprogramm einen derartigen Timer definiert und „aufzieht" und später, wenn der betreffende Timer abgelaufen ist, benachrichtigt wird. Diese Benachrich tigung kann weiterhin mit dem Aufruf einer speziellen Handler-Routine verbunden sein, d.h. einer Anwendung (Task), die eine von einem Benutzer festgelegte Reaktion auf den Timerablauf ausführt, z.B. eine bestimmte Automatisierungseinheit in einer zu steuernden Anlage stoppt, oder dergleichen. Mit wachsender Anzahl verwalteter Timer steigt dabei jedoch entweder die Belastung des Systems, und/oder es sinkt dessen Realtime-Fähigkeit.

Bei vorbekannten Datenverarbeitungssystemen wird üblicherweise der Minimierung der Belastung der Vorzug gegeben. Dies ist gleichbedeutend damit, dass unabhängig von der Anzahl der zu verwaltenden Timer zu einer bestimmtem Zeit, d.h. bei einem gegebenen Timer-Tick-Interrupt nur diejenigen Timer durch das Betriebssystem behandelt werden, deren Zeit zu diesem Tick auch abgelaufen ist. Ein solcher Ansatz ist möglich, wenn alle vorhandenen Timer gemäß ihrem Ablaufzeitpunkt in einer Warteschlange geordnet werden. In nachteiliger Weise für die Echtzeitfähigkeit des Systems ergeben sich auf diese Weise nicht unterbrechbare Zeiten für das Einsortieren eines Timers in die Warteschlange, wofür zudem keine akzeptabel kleinen Maximalzeiten garantiert werden können, was die Einsetzbarkeit als Echtzeit fähiges System, beispielsweise für Automatisierungsaufgaben, weiter einschränkt.

Ein fortschrittlicher Ansatz zur Verwaltung von Software-Timern ist für den LINUX-Betriebssystemkernel bekannt (vgl. Maurer, Wolfgang: Linux Kernelarchitektur, Hanser Verlag (ISBN 3-446-22566-8), Seite 622 ff), ohne jedoch eine Lösung für die Problematik undefinierbar langer, nicht unterbrechbarer Zeiten beim Umsortieren von Timer-Warteschlangen anzugeben, was sich nachteilig auf die Echtzeitfähigkeit auswirkt. Zudem benötigt der vorbekannte Ansatz in nachteiliger Weise eine relative große Menge an Speicherplatz.

Der Erfindung liegt die Aufgabe zu Grunde, ein Verfahren bzw. ein Datenverarbeitungssystem zu schaffen, sodass auch bei einer großen, ggf. unbekannten Anzahl von verwalteten Software-Timern die garantierten Reaktionszeiten für zeitkritische Aufgaben vorhersagbar klein bleiben, ohne dass bei der Realisierung zusätzlicher Overhead entsteht. Das so geschaffene Verfahren bzw. Datenverarbeitungssystem soll insbesondere zur Echtzeit-Steuerung von Anlagen und Automatisierungseinheiten einsetzbar sein. Zudem soll die Verwendbarkeit von existierenden nach dem POSIX-Standard konzipierten APls (Application Programming Interfaces) auch für extrem zeitkritische Automatisierungsaufgaben gewährleistet bleiben.

Die Aufgabe wird erfindungsgemäß gelöst durch ein Verfahren zum Implementieren von Software-Timern, wobei eine Gesamtmenge von Software-Timern in Teilmengen aufgeteilt wird und wobei jede Teilmenge auf einem jeweils festgelegten Prioritätsniveau bearbeitet wird. Der Grundgedanke der vorliegenden Erfindung ist demnach die transparente Aufteilung der Timer-Gesamtmenge in Timer-Verwaltungscluster, die auf unterschiedlichen Prioritätsebenen bearbeitet werden, ohne dass dabei zusätzlicher Overhead entsteht.

Die Aufgabe wird auch gelöst durch ein Datenverarbeitungssystem der eingangs genannten Art, bei dem ein in der Speichereinheit gespeicherter zweiter Programmcode vorgesehen ist, durch den bei Ausführung in der Prozessoreinheit ein Programmcode-Mechanismus generierbar ist, der zum Aufteilen der Gesamtmenge von Software-Timern in Teilmengen und zum Bearbeiten jeder Teilmenge auf einem jeweils festgelegten Prioritätsniveau ausgebildet ist.

Die Aufgabe wird weiterhin bei dem eingangs genannten Verfahren zum Verwalten einer Menge von Software-Timern dadurch ge löst, dass alle Software-Timer mit einer Ablaufzeit in einem Abstand von mehr als N1·N2 Zeitsignalen von einer aktuellen Zeit einer gemeinsamen Überlauf-Warteschlange zugeordnet werden.

Zusätzlich wird die Aufgabe auch gelöst durch das eingangs genannte Datenverarbeitungssystem mit in der Speichereinheit gespeichertem weiteren Programmcode, durch den bei Ausführung in der Prozessoreinheit der ebenfalls eingangs beschriebene Programmcode-Mechanismus generierbar ist, bei dem der Programmcode-Mechanismus zum Zuordnen aller Software-Timer mit einer Ablaufzeit in einem Abstand von mehr als N1·N2 Zeitsignalen von einer aktuellen Zeit zu einer gemeinsamen Überlauf-Warteschlange ausgebildet ist.

Nach einer ersten Weiterbildung des erfindungsgemäßen Verfahrens ist vorgesehen, dass jede Teilmenge von Software-Timern durch einen zugeordneten List-Header verwaltet wird, wobei jeder Eintrag in dem List-Header den Warteschlangenkopf einer Warteschlange von Software-Timern bildet, welche zu einem gemeinsamen Zeitpunkt ablaufen. Entsprechend besitzt ein erfindungsgemäßes Datenverarbeitungssystem vorzugsweise einen weiteren Programmcode-Mechanismus, der zum Verwalten jeder Teilmenge von Software-Timern durch einen zugeordneten List-Header ausgebildet ist, wobei jeder Eintrag in dem List-Header den Warteschlangenkopf einer Warteschlange von Software-Timern bildet, welche zu einem gemeinsamen Zeitpunkt ablaufen, sodass eine Kompatibilität mit bestehenden Standards und Implementierungen gegeben ist.

Vorteilhafter Weise kann bei einem erfindungsgemäßen Verfahren weiterhin vorgesehen sein, dass die Aufteilung der Software-Timer in Abhängigkeit von einer Zeitkritizität der ihnen jeweils zugeordneten Anwendungen erfolgt. Dementsprechend be sitzt eine Weiterentwicklung des erfindungsgemäßen Datenverarbeitungssystems einen weiteren Programmcode-Mechanismus, der zum Aufteilen der Software-Timer in Abhängigkeit von einer Zeitkritizität der ihnen jeweils zugeordneten Anwendungen ausgebildet ist. Auf diese Weise ist gewährleistet, dass besonders zeitkritische Timer bzw. die ihnen zugeordneten Tasks gemäß dem Grundgedanken der vorliegenden Erfindung prioritär über eine eigene Verwaltungsstruktur bearbeitet werden können.

Folglich kann verfahrensmäßig weiterhin vorgesehen sein, dass wenigstens eine erste Teilmenge von Software-Timern auf Echtzeit-Ebene behandelt wird, um eine optimale Echtzeitfähigkeit zu gewährleisten. Weiterhin kann vorgesehen sein, dass wenigstens eine zweite Teilmenge von Software-Timern auf Task-Ebene behandelt wird. Entsprechende Weiterbildungen des erfindungsgemäßen Datenverarbeitungssystems beinhalten einen weiteren Programmcode-Mechanismus, der zum Behandeln wenigstens einer ersten Teilmenge von Software-Timern auf Echtzeit-Ebene ausgebildet ist bzw. einen weiteren Programmcode-Mechanismus, der zum Behandeln wenigstens einer zweiten Teilmenge von Software-Timern auf Task-Ebene ausgebildet ist.

Um die Echtzeitfähigkeit des erfindungsgemäßen Verfahrens zu optimieren, kann sich eine andere Weiterbildung dadurch auszeichnen, dass für die zweite Teilmenge auf Echtzeit-Ebene lediglich festgestellt wird, ob der zugeordnete List-Header einer Bearbeitung bedarf, insbesondere wegen Ablauf wenigstens eines Software-Timers oder einer erforderlichen Umsortierung wenigstens einer Warteschlange. Die Bearbeitung selbst erfolgt dann vorzugsweise auf niederpriorer Task-Ebene, wobei außerdem in vorteilhafter Weiterbildung die Bearbeitung durch einen höherprioren Task jederzeit unterbrechbar ist. Entsprechende Weiterbildungen des erfindungsgemäßen Da tenverarbeitungssystems sehen einen weiteren Programmcode-Mechanismus vor, der zum Feststellen auf Echtzeit-Ebene dahingehend ausgebildet ist, ob der zugeordnete List-Header der zweiten Teilmenge einer Bearbeitung bedarf, insbesondere wegen Ablauf wenigstens eines Software-Timers oder einer erforderlichen Umsortierung wenigstens einer Warteschlange bzw. einen weiteren Programmcode-Mechanismus, der im Falle einer positiven Feststellung zum Bearbeiten des List-Headers ausgebildet ist, wobei die Bearbeitung durch einen höherprioren Task unterbrechbar ist.

Um Konsistenzprobleme bei der Bearbeitung von Warteschlangen auf niederpriorer Task-Ebene zu vermeiden, kann bei einem erfindungsgemäßen Verfahren weiterhin vorgesehen sein, dass eine umzusortierende Warteschlange für einen Zugriff durch andere Anwendungen gesperrt ist. In Weiterbildung des erfindungsgemäßen Verfahrens lässt sich dies insbesondere dadurch erreichen, dass eine umzusortierende Warteschlange an einen temporären Warteschlangenkopf angehängt wird und dass von dort aus die Umsortierung erfolgt. Vorteilhafte entsprechende Weiterbildungen des erfindungsgemäßen Datenverarbeitungssystems besitzen in diesem Zusammenhang einen weiteren Programmcode-Mechanismus, der zum Sperren einer umzusortierenden Warteschlange für einen Zugriff durch andere Anwendungen ausgebildet ist bzw. einen weiteren Programmcode-Mechanismus, der zum Anhängen einer umzusortierenden Warteschlange an einen ausgezeichneten Warteschlangenkopf ausgebildet ist, sodass die Umsortierung von dort aus erfolgt.

Um eine CPU-Belastung des Systems auch für eine große Anzahl von Timern gering zu halten, sieht eine äußerst bevorzugte Ausgestaltung des erfindungsgemäßen Verfahrens vor, dass bei Ablauf eines Software-Timers aus einer nicht Echtzeit relevanten Teilmenge von Software-Timern ein Aufruf eines betref fenden Timer-Handlers durch dieselbe Trägertask vorgenommen wird, die für ein Verwalten der entsprechenden Teilmenge, d.h. für die Bearbeitung des entsprechenden List-Headers, zuständig ist. Dementsprechend kann ein erfindungsgemäßes Datenverarbeitungssystem einen weiteren Programmcode-Mechanismus aufweisen, der bei Ablauf eines Software-Timers aus einer nicht Echtzeit relevanten Teilmenge von Software-Timern zum Veranlassen eines Aufrufens eines betreffenden Timer-Handlers durch dieselbe Trägertask ausgebildet ist, die für ein Verwalten der entsprechenden Teilmenge, insbesondere für die Bearbeitung des entsprechenden List-Headers, zuständig ist.

Weitere Eigenschaften und Vorteile der Erfindung ergeben sich aus der folgenden Beschreibung von Ausführungsbeispielen anhand der Zeichnung. Es zeigt:
1 ein schematisches Blockschaltbild eines erfindungsgemäßen Datenverarbeitungssystems;
2 eine schematische Darstellung einer erfindungsgemäßen List-Header-Datenstruktur;
3 ein Flussdiagramm zur Erläuterung einer erfindungsgemäßen Prüfung des List-Headers in 2 auf Timerablauf und einer Umsortierung von Warteschlangen;
4 eine schematische Darstellung der erfindungsgemäß differenzierten Behandlung von Warteschlangen-Teilmengen unterschiedlicher Priorität; und
5 ein Flussdiagramm zur Erläuterung einer erfindungsgemäßen Vermeidung von Konsistenzproblemen beim Umsortieren von Warteschlangen gemäß 3.
Die 1 zeigt ein schematisches Blockschaltbild eines erfindungsgemäßen Datenverarbeitungssystems 1. Das Datenverarbeitungssystem 1 weist zunächst eine Datenverarbeitungsanlage 2 mit einer Prozessoreinheit 3 und einer Speichereinheit 4 auf, wobei die Speichereinheit 4 als flüchtiger und/oder nicht flüchtiger Speicher ausgebildet sein kann, was dem Fachmann geläufig ist. Die Prozessoreinheit 3 ist zum Ausführen von Echtzeit-Anwendungen und zum Ausführen von Nicht-Echtzeit-Anwendungen oder Tasks ausgebildet, was in der 1 mittels der Bereiche ISR (Interrupt Service Routine) bzw. TASK symbolisiert ist. Für den Einsatz bei (zeitkritischen) Automatisierungsaufgaben steht die Datenverarbeitungsanlage 2 mit einer höchst schematisch als Feld 5 von Automatisierungseinheiten 6.1, 6.2, 6.3, ... dargestellten Anlage in Wirkverbindung, wobei die einzelnen Automatisierungseinheiten 6.1, 6.2, 6.3, ... untereinander z.B. über ein geeignetes Bussystem 7 verbunden sind.
In seiner Speichereinheit 4 weist das Datenverarbeitungssystem 1 weiterhin eine Anzahl von Programmcode-Einheiten 8.1, 8.2, ..., die in der Prozessoreinheit 3 ausführbar sind und dort zur Entstehung von Programmcode-Mechanismen 9.1-9.4, ... führen, wobei einige dieser Programmcode-Mechanismen 9.1, 9.3, ... im Echtzeit-Bereich ISR und andere Programmcode-Mechanismen 9.2, 9.4, ... im Nicht-Echtzeit-Bereich TASK der Prozessoreinheit 3 angeordnet sind. Ebenfalls dargestellt sind eine Anzahl von im Zuge der Programmausführung in der Prozessoreinheit 3 erzeugter Software-Timer 10.1-10.6, ..., bei denen wiederum je nach zugeordneter Anwendung zwischen Echtzeit kritischen Software-Timern 10.1, 10.3, 10.5, ... und nicht Echtzeit kritischen Software-Timern 10.2, 10.4, 10.6, ... unterschieden wird. Diese Software-Timer sind im Folgenden alternativ auch kurz als „Timer" bezeichnet. Für die erfindungsgemäße Gruppierung der Software-Timer 10.1-10.6 in Teilmengen unterschiedlicher Priorität sind in der Speichereinheit 4 eine Anzahl von List-Header-Datenstrukturen 11.1, 11.2, 11.3, ... angelegt, deren Funktion und Bedeutung nachfolgend unter Bezugnahme auf die 2 noch detailliert erläutert wird. Bei den angesprochenen Programmcode-Mechanismen 9.1, 9.2, ... kann es insbesondere um Mechanismen zur Erzeugung der Software-Timer 10.1-10.6, ..., zum Einsortieren der Timer in Warteschlangen abhängig von einer Timer-Ablaufzeit, zum Überprüfen der Timer auf Zeitablauf, zum Aufrufen sog. Timer-Handler bei Zeitablauf oder weiterer Programmcode-Mechanismen gemäß den beigefügten Patentansprüchen handeln, wie weiter unten insbesondere anhand der 2 und 4 noch deutlicher werden wird. So kann beispielsweise ein spezieller Timer-Handler einen zeitkritischen Steuerungsvorgang bei einer der Automatisierungseinheiten 6.1-6.3 auslösen. Darüber hinaus weist das Datenverarbeitungssystem 1 in der Datenverarbeitungsanlage 2 noch einen Hardware-Tickgenerator 12 auf, der in zeitlich regelmäßigen Abständen (z.B. alle 100 μs) Zeitsignale in Form von Timer-Tick-Interrupts erzeugt, welche für die im Folgenden beschriebene Behandlung von Software-Timern maßgeblich sind.
Mit der Datenverarbeitungsanlage 2 ist weiterhin eine Dateneingabeeinheit 13 verbunden, bei der es sich um jede bekannte Art von Gerät zum Einlesen Computer lesbarer Datenträgermedien 14 handeln kann, z.B. um ein CD-ROM-Lesegerät zum Lesen von Daten von einer CD-ROM. Auf diese Weise lässt sich die beschriebene softwaretechnische Einrichtung der Datenverarbeitungsanlage 2 in vorteilhafter Weise mittels eines entsprechenden, auf einem geeigneten Datenträger 14 gespeicherten Computerprogrammprodukts realisieren.
Schließlich ist in der Speichereinheit 4 des Datenverarbeitungssystems 1 noch eine temporäre interne Variable 15 vorhanden, deren Eigenschaften und Funktion weiter unten unter Bezugnahme auf die 5 detailliert beschrieben wird.
Die 2 zeigt eine schematische Darstellung einer erfindungsgemäßen List-Header-Datenstruktur 11.x (vgl. 1), im Folgenden kurz als List-Header bezeichnet, wobei allgemein „x" abkürzend für die Ziffern „1, 2, 3, ..." gemäß der 1 verwendet wird. Der List-Header 11.x dient zum Verwalten einer (Teil-)Menge von Software-Timern 10.x, wobei ein bestimmter List-Header 11.x – und somit die in ihm verwaltete (Teil-)Menge von Software-Timern 10.x – nach der Grundidee der vorliegenden Erfindung entweder dem Echtzeit-Bereich ISR oder dem Nicht-Echtzeit-Bereich TASK der Prozessoreinheit 3 (vgl. 1) zugeordnet ist.
Jeder List-Header 11.x weist unabhängig von dieser Zuordnung drei Bereiche auf, nämlich einen ersten Bereich 11.xa, einen zweiten Bereich 11.xb sowie einen dritten Bereich 11.xc. In seinem ersten Bereich 11.xa beinhaltet der List-Header 11.x zunächst eine Anzahl von N1 Warteschlangenköpfen K1, K2, K3, ... für Software-Timer 10.x, wobei N1 eine vorgegebene natürliche Zahl ist. Jeder Warteschlangenkopf Kx verweist auf einen (ersten) Software-Timer 10.x, an den sich die jeweils weiteren Timer einer Warteschlange in Form einer verketteten Liste (linked list) anschließen, was in 2 anhand einer Warteschlange W1 exemplarisch dargestellt und dem Fachmann an sich geläufig ist. Alle Timer 10.x einer Warteschlange laufen zu einer gleichen Zeit t ab, die durch die Position des Warteschlangenkopfes Kx in der List-Header-Struktur 11.x festgelegt ist.
In dem ersten Bereich 11.xa des List-Headers 11.x ist jedem Tick einer Reihe von L1 aufeinander folgenden Ticks des Tickgenerators 12 (1) ein Warteschlangenkopf Kx bzw. eine Warteschlange zugeordnet. Wenn man die absolute (System-)Zeit t in Form einer Tick-Datenstruktur T mit 64 Bits (64-Bit Integer) darstellt, so entsprechen gemäß einer bevorzugten Aus gestaltung der vorliegenden Erfindung einer Anzahl von L1 Bits am Ende der Tick-Datenstruktur T, d.h. diejenigen Bits, die sich beim bitweisen Inkrementieren der Systemzeit t am häufigsten verändern, genau N1 = 2^L1 Warteschlangenköpfe Kx in dem ersten Bereich 11.xa des List-Headers 11.x. Die o.g. L1 Bits der Datenstruktur T werden auch als L1-Feld bezeichnet. Gemäß einer bevorzugten Ausgestaltung der vorliegenden Erfindung besitzt L1 den Wert 5, sodass sich in ersten Bereich des List-Headers 11.x N1 = 2⁵ = 32 Warteschlangenköpfe Kx ergeben. Entsprechend entfallen nach Maßgabe der nächsten L2 höheren Bits der Tick-Datenstruktur T gerade N2 = 2^L2 Warteschlangenköpfe Kx auf den zweiten Bereich 11.xb des List-Headers 11.x, wobei zeitlich gesehen auf 2^L1 Ticks jeweils ein Warteschlangenkopf Kx aus dem zweiten Bereich 11.xb kommt. Die o.g. L2 Bits der Datenstruktur T werden auch als L2-Feld bezeichnet. Mit anderen Worten: In dem zweiten Bereich 11.xb des List-Headers 11.x mit einer zweiten Anzahl N2 von Warteschlangenköpfen Kx ist jedem Warteschlangenkopf Kx der zweiten Anzahl N2 von Warteschlangenköpfen Kx eine Warteschlange mit Software-Timern 10.x zugeordnet wird, deren Ablaufzeiten t ein gesamtes, durch den Wert von N1 definiertes Zeitintervall überstreichen.
Der dritte Bereich 11.xc beinhaltet nur einen einzigen Warteschlangenkopf Ky, der eine sog. Überlauf-Warteschlange (Overflow List) OL anführt, in der alle Software-Timer 10.x mit einer Ablaufzeit aufgeführt sind, die mehr als 2^L1+L2 = N1·N2 Ticks Abstand von der aktuellen Systemzeit t bzw. T besitzen.
Auf diese Weise unterscheidet sich die vorliegende Erfindung von der in herkömmlichen LINUX-Systemen vorgesehenen List-Header-Struktur, die aufgrund einer Adressierung des List-Headers mit einer 32-Bit Tick-Datenstruktur (32-Bit Wort mit Aufteilung L1 = 8, L2 = 6, L3 = 6, L4 = 6, L5 = 6) eine Anzahl von 2³¹ = 512 Warteschlangenköpfen bereitstellt, wobei jedoch in Ermangelung einer erfindungsgemäßen Überlauf-Warteschlange OL keine Timer mit einem zeitlichen Tick-Abstand größer 2³¹ Ticks verwaltet werden können. Mit der hier vorgeschlagenen Ausgestaltung des List-Headers 11.x lässt sich bei effektiver Begrenzung der Anzahl an Warteschlangenköpfen bzw. Warteschlangen dennoch der gesamte im POSIX-Standard geforderte Wertebereich für Timer-Ablaufzeiten zur Verfügung stellen, was eine optimierte Ausnutzung von verfügbaren Ressourcen ermöglicht.
Die 3 zeigt anhand eines Flussdiagramms den Ablauf einer erfindungsgemäßen Prüfung des List-Headers 11.x in 2 auf Timerablauf und der ggf. damit verbundenen Umsortierung von Warteschlangen. Das Prüfungsverfahren startet in Schritt 300. In einem anschließenden Schritt 302 wird die Tick-Datenstruktur T (2) inkrementiert, d.h. ihr wird ein um einen Bit-Wert erhöhter Wert für die Systemzeit zugewiesen, indem durch den Hardware-Tickgenerator 12 (1) ein entsprechender Timer-Tick-Interrupt erzeugt wird. Daraufhin erfolgt in Schritt 304 eine Abfrage dahingehend, ob alle L1-Bits (beispielsweise die letzten fünf Bits, d.h. die niedrigwertigsten Bits) der Datenstruktur T den Wert Null besitzen, was nach jeweils 2^L1 Ticks der Fall ist. Wird diese Abfrage verneint (n), so erfolgt anschließend in Schritt 306 eine Abfrage des aktuell durch das L1-Feld adressierten Warteschlangenkopfes aus dem ersten Bereich 11.xa des List-Headers 11.x (2) mittels eines geeigneten Programmcode-Mechanismus 9.x (1), was dem Fachmann geläufig ist. Besitzen beispielsweise die L1 Bits des L1-Feldes die Werte 0, 0, 1, 0, 1, d.h. T = |...|...|0|0|1|0|1|, so wird dadurch der fünfte Warteschlangenkopf K5 adressiert und die entsprechende Warteschlange abgefragt. Danach wird in Schritt 308 der Ablauf der in dieser Warteschlange enthaltenen Timer signalisiert, sodass die ent sprechenden Handler-Routinen aufgerufen werden können. Dies wird nachfolgend anhand der 4 noch eingehender erläutert. In Schritt 310 wird dann die abgefragte Warteschlange aus dem List-Header entfernt, und der Verfahrensablauf wird mit Schritt 302 (s.o.) fortgesetzt.
Wird die Abfrage in Schritt 304 bejaht (j), so erfolgt in einem anschließenden Schritt 312 eine weitere Abfrage dahingehend, ob auch alle Bits des L2-Feldes der Datenstruktur T (2) den Wert Null besitzen. Wird diese Abfrage verneint (n), so erfolgt anschließend in Schritt 314 eine Abfrage des aktuell durch das L2-Feld adressierten Warteschlangenkopfes aus dem zweiten Bereich 11.xb des List-Headers 11.x (2) mittels eines geeigneten Programmcode-Mechanismus 9.x (1), und die zugehörige aktuelle L2-Warteschlange wird mittels eines weiteren geeigneten Programmcode-Mechanismus 9.x auf die L1-Warteschlangen, d.h. alle Warteschlangen mit einem Warteschlangenkopf Kx aus dem ersten Bereich 11.xa des List-Headers 11.x aufgeteilt (umsortiert). Anschließend wird in Schritt 316 die betreffende L2-Warteschlange aus dem List-Header entfernt, und der Verfahrensablauf wird mit Schritt 302 (s.o.) fortgesetzt.
Wird dagegen die Abfrage in Schritt 312 bejaht (j), d.h. alle L1-Bits und alle L2-Bits sind gleich Null, so wird in einem anschließenden Schritt 318 die Überlauf-Warteschlange OL auf alle L1- und L2-Warteschlangen sowie auf die Überlauf-Warteschlange OL selbst verteilt, d.h. es findet wiederum eine Umsortierung statt. Danach wird der Verfahrensablauf ebenfalls mit Schritt 302 (s.o.) fortgesetzt.
Auf diese Weise kann für den List-Header 11.x gemäß der 2 mit dem vorstehend beschriebenen Verfahren innerhalb einer entsprechenden sog. „Clock-Tick-Routine", d.h. einem geeigne ten Programmcode-Mechanismus 9.x mit nur einer Abfrage (der durch das aktuell veränderte L1-Bit adressierten Warteschlange) festgestellt werden, ob mindestens ein Timer abgelaufen ist – wenn eine entsprechende Warteschlange existiert – oder nicht.
Auf die Problematik der Konsistenz von Warteschlangen im Zuge der vorstehend beschriebenen Umsortierung wird weiter unten unter Bezugnahme auf die 5 noch detailliert eingegangen.
Die 4 zeigt eine schematische Darstellung der erfindungsgemäß differenzierten Behandlung von Warteschlangen-Teilmengen unterschiedlicher Priorität. Wie bereits erwähnt, wird erfindungsgemäß die vorhandene Gesamtmenge von Software-Timern 10.x (1) in Teilmengen unterschiedlicher Priorität bei der Abarbeitung aufgeteilt. Auf der Basis des POSIX-Standards können derartige Teilmengen z.B. anhand unterschiedlicher Funktionalitäten definiert werden: 1) Teilmenge „Anwender-Timer 1", die bei Ablauf ein Signal an den Anwender senden und Echtzeit-Relevanz besitzen können; 2) Teilmenge „Anwender-Timer 2", die bei Ablauf eine vom Anwender bestimmte Handler-Routine aufrufen und die ebenfalls Echtzeit-Relevanz besitzen können; oder 3) Kernel-interne Timer auf Betriebssystemebene, die typischer Weise keine Echtzeit-Relevanz besitzen. Eine weitere Gruppierungsmöglichkeit ergäbe sich bei Benutzung unterschiedlicher, zusätzlich eingeführter Clocks. In der vorliegenden 4 sind exemplarisch drei Timer-Teilmengen 11.1, 11.2, 11.4 mit jeweils einer Anzahl von Software-Timern 10.x (vgl. 1) dargestellt, wobei nur die Teilmenge 11.1 Echtzeit kritisch ist. Jede der drei Teilmengen 11.1, 11.2, 11.4 wird durch einen List-Header 11.x gemäß der 2 und in Abhängigkeit von Timer-Tick-Interrupts des Hardware-Tickgenerators 12 (1) („HW-Tick") verwaltet, wie weiter oben bereits detailliert beschrieben wurde. Mit der erfindungsgemäßen Gruppierung von Timern in Teilmengen lässt sich vorteilhafter Weise erreichen, dass nur eine bekannte Menge von zeitkritischen Anwender-Timern direkt auf ISR-Ebene behandelt wird.
Nach der Darstellung in 4 ist nur die Teilmenge 11.1, d.h. der entsprechende List-Header auf Echtzeit-Ebene ISR angeordnet, während die weiteren List-Header 11.2, 11.4 nur zeitlich unkritische Timer 10.x verwalten, die mit niedriger Priorität auf Task-Ebene TASK behandelt werden. Beispielsweise kann es sich bei dem List-Header 11.4 um einen sog. „Timeout List Header" handeln, der Software-Timer 10.x verwaltet, die ein zu langes Warten des Benutzers bei bestimmten Betriebssystem-Aufrufen vermeiden sollen. Somit lässt sich im Falle einer erforderlichen Umsortierung von Warteschlangen, z.B. aufgrund neu erzeugter Timer, eine maximale Zeit angeben, während der die ISR-Ebene nicht-unterbrechbar belegt ist. Für die o.g. weiteren List-Header bzw. Teilmengen 11.2, 11.4 wird auf ISR-Ebene nur überprüft (mit „check" bezeichnete Pfeile in 4), ob der betreffende List-Header 11.2, 11.4 einer Bearbeitung bedarf, wie oben unter Bezugnahme auf die 3 exemplarisch beschrieben wurde. Unter „erforderlicher Bearbeitung" ist dabei hier und im Folgenden allgemein zu verstehen, dass wenigstens ein Timer abgelaufen ist und entsprechende Maßnahmen zur Signalisierung und/oder zur Bereinigung der List-Header-Struktur erforderlich sind bzw. dass wenigstens eine Warteschlange einer Umsortierung bedarf, z.B. weil alle L1-Bits den Wert Null angenommen haben. Nur dann wird erfindungsgemäß eine betreffende Task aufgerufen, wie eine Trägertask (carrier task) CT im Falle des List-Headers 11.2 oder eine Kernel-interne Task KT im Falle des List-Headers 11.4, die dann ihrerseits eine vollständige Behandlung des List-Headers 11.2 bzw. 11.4 durchführt, wie weiter oben anhand der 3 beschrieben. Dies ist in der 4 jeweils mittels eines Doppelpfeils zwischen dem betreffenden List-Header 11.2, 11.4 und der zugehörigen Task CT bzw. KT symbolisiert. Dabei ist die vollständige Behandlung eines betreffenden List-Headers 11.2, 11.4 jederzeit durch eine Anwendertask mit höherer Priorität unterbrechbar. Dies gilt insbesondere für das Umsortieren, wobei eine komplette Warteschlange von grundsätzlich unbekannter Länge bearbeitet werden muss. Das Aufrufen oder Aktivieren der Tasks CT, KT ist mittels gestrichelter Pfeile („wake_up") von der ISR-Ebene, auf der die Überprüfung der List-Header auf erforderliche Bearbeitung stattfindet, zu der jeweiligen Task CT, KT dargestellt. Nach Maßgabe eines entsprechenden Wakeup-Signals an einen Programmcode-Mechanismus 9.2 („sigwait"), welcher bestimmten Tasks CT zugeordnet ist, startet dieser die Ausführung der jeweiligen Task CT. Gemäß dem in 4 dargestellten Ausführungsbeispiel muss nur die Trägertask über den sigwait-Mechanismus 9.2 gehen, da dies die (von POSIX bzw. Linux-Kernel) vorgegebene Schnittstelle für das Anwendungsprogramm ist.)
Ein entsprechender, jedoch leicht abgewandelter Mechanismus existiert gemäß der 4 für extrem zeitkritische Tasks ETT1, ETT2: Die zugehörigen Timer 10.x werden in einem eigenen ISR-List-Header 11.1 („ISR List Header") direkt auf ISR-Ebene verwaltetet. Nach Maßgabe eines Timer-Tick-Interrupts („HW-Tick") erfolgt hier die Prüfung und Bearbeitung des List-Headers 11.1 (vgl. 3) vollständig auf der Echtzeit-Ebene ISR. Wird ein Timerablauf festgestellt, d.h. wenigstens ein Timer einer aktuell angesprochenen L1-Warteschlange (2) „feuert", so ergeht ein entsprechendes Timer-Signal TS1, TS2 an die zugeordnete zeitkritische Task ETT1 bzw. ETT2 bzw. an einen der betreffenden Task ETT1, ETT2 zugeordneten Programmcode-Mechanismus 9.4 bzw. 9.6 („sigwait"), und dieser startet die Ausführung der jeweiligen extrem zeitkritischen Task ETT1, ETT2, beispielsweise zur Steuerung von Automatisierungseinheiten 6.x gemäß der 1.
Nach einer weiteren besonders bevorzugten Ausgestaltung der vorliegenden Erfindung erfolgt das Aufrufen von Timer-Handlern 9.8, d.h. Stücken von Programmcode bzw. daraus erzeugten Programmcode-Mechanismen zum Hervorrufen einer bestimmten Reaktion auf den Ablauf eines oder mehrerer Timer (vgl. POSIX-Definition) ausgehend von derjenigen Trägertask CT, die auch für Bearbeitung des entsprechenden List-Headers – hier des List-Headers 11.2 – verantwortlich ist.
Bei der weiter oben unter Bezugnahme auf die 3 angesprochenen Umsortierung von Warteschlangen auf (niederpriorer) Task-Ebene (Doppelpfeile in 4) ergibt sich zusätzlich noch das Problem der Konsistenz der betreffenden Warteschlangen, die gemäß der gegebenen Beschreibung der 2 als vorwärts und rückwärts verkettete Listen (linked lists) ausgebildet sind: Auf diese Weise ist es prinzipiell möglich, dass eine gegebene Warteschlange gleichzeitig durch mehrere Tasks modifiziert wird, was zu den angesprochenen Konsistenzproblemen führen kann. Diese werden im Rahmen der vorliegenden Erfindung durch eine nachfolgend unter Bezugnahme auf die 5 beschriebene Prozedur gelöst:
Die 5 zeigt ein Flussdiagramm zur Erläuterung einer erfindungsgemäßen Vermeidung von Konsistenzproblemen beim Umsortieren von Warteschlangen gemäß 3. Das Verfahren startet in Schritt 500. In einem anschließenden Schritt 502 wird abgefragt, ob und ggf. welche Warteschlange umzusortieren ist. Dabei kann es sich gemäß der oben gegebenen Beschreibung der 3 entweder um die Überlauf-Warteschlange OL (2) oder um eine der L2-Warteschlangen handeln. Die L1-Warteschlangen besitzen eine eindeutige Zuordnung der in ihnen verwalteten Timer zu einem Timer-Tick-Interrupt und müssen somit nicht mehr umsortiert werden. Wird die Abfrage in Schritt 502 bejaht (j), so wird die identifizierte, umzusortierende und durch einen Warteschlangenkopf festgelegte Warteschlange in Schritt 504 aus dem betreffenden List-Header 11.x entfernt („abgehängt") und in einem nachfolgenden Schritt 506 an eine zusätzliche interne Variable 15 (1) in Form eines sog. „Headers" entsprechend einem einzelnen unabhängigen Warteschlangenkopf „angehängt". Von dort aus erfolgt dann in Schritt 508 die beschriebene Umsortierung der Warteschlange. Dadurch, dass die umzusortierende Warteschlange aus ihrem List-Header entfernt wurde, ist sie effektiv für einen Zugriff durch andere Tasks unzugänglich („gesperrt"), wobei das Umsortieren selbst – wie gesagt – durch Anwendungen mit höherer Priorität jederzeit abbrechbar ist. Nach erfolgter Umsortierung werden die entfernte Warteschlange (im Falle einer abgehängten Überlauf-Warteschlange OL) und/oder die neu erzeugten L2 bzw. L1-Warteschlangen (Erstere nur im Falle einer entfernten Überlauf-Warteschlange OL) in Schritt 510 wieder in den ursprünglichen List-Header 11.x eingehängt, wobei allerdings der Einhängvorgang atomar sein muss, d.h. nicht unterbrochen werden darf. Auf diese Weise lassen sich erfindungsgemäß die nicht unterbrechbaren Bearbeitungszeiten der List-Header zwecks einer gesteigerten Echtzeitfähigkeit reduzieren. Wenn keine (weiteren) Warteschlangen umzusortieren sind (verneinte Abfrage (n) in Schritt 502), endet das Verfahren in Schritt 512.
Erfindungsgemäß kann nunmehr unabhängig von der vorhandenen Anzahl an Timern für die Reaktionszeit von zeitkritischen Tasks eine sehr kurze maximale Reaktionszeit garantiert werden. Gleichzeitig wird die CPU-Belastung auch für eine große Anzahl von Timern gering gehalten. Letzteres gilt insbesondere dann, wenn – wie vorstehend beschrieben – für die Aktivie rung von Handlern die Trägertask für einen betreffenden Handler identisch ist mit derjenigen Task, die den zugehörigen List-Header bearbeitet, da hierbei zusätzliche nachteilige Taskwechsel vermieden werden.

Claims

Verfahren zum Implementieren von Software-Timern, wobei eine Gesamtmenge von Software-Timern in Teilmengen aufgeteilt wird und wobei jede Teilmenge auf einem jeweils festgelegten Prioritätsniveau bearbeitet wird.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass jede Teilmenge von Software-Timern durch einen zugeordneten List-Header verwaltet wird, wobei jeder Eintrag in dem List-Header den Warteschlangenkopf einer Warteschlange von Software-Timern bildet, welche zu einem gemeinsamen Zeitpunkt ablaufen.
Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die Aufteilung der Software-Timer in Abhängigkeit von einer Zeitkritizität der ihnen jeweils zugeordneten Anwendungen erfolgt.
Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass wenigstens eine erste Teilmenge von Software-Timern auf Echtzeit-Ebene behandelt wird.
Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass wenigstens eine zweite Teilmenge von Software-Timern auf Task-Ebene behandelt wird.
Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass für die zweite Teilmenge auf Echtzeit-Ebene festgestellt wird, ob der zugeordnete List-Header einer Bearbeitung bedarf, insbesondere wegen Ablauf wenigstens eines Software-Timers oder einer erforderlichen Umsortierung wenigstens einer Warteschlange.
Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass im Falle einer positiven Feststellung die Bearbeitung des List-Headers erfolgt, wobei die Bearbeitung durch einen höherprioren Task unterbrechbar ist.
Verfahren nach einem der Ansprüche 2 bis 7, dadurch gekennzeichnet, dass eine umzusortierende Warteschlange für einen Zugriff durch andere Anwendungen gesperrt wird.
Verfahren nach einem der Ansprüche 2 bis 8, dadurch gekennzeichnet, dass eine umzusortierende Warteschlange oder ein umzusortierender Teil einer Warteschlange an einen temporären Warteschlangenkopf angehängt wird und dass von dort aus die Umsortierung erfolgt.
Verfahren nach einem der Ansprüche 2 bis 9, dadurch gekennzeichnet, dass bei Ablauf eines Software-Timers aus einer nicht Echtzeit relevanten Teilmenge von Software-Timern ein Aufruf eines betreffenden Timer-Handlers durch dieselbe Trägertask vorgenommen wird, die für ein Verwalten der entsprechenden Teilmenge, insbesondere für die Bearbeitung des entsprechenden List-Headers, zuständig ist.
Verfahren zum Verwalten einer Menge von Software-Timern, insbesondere nach einem der vorangehenden Ansprüche, wobei alle zu einem gemeinsamen Zeitpunkt ablaufenden Software-Timer in eine Warteschlange mit einem Warteschlangenkopf eingeordnet werden, wobei die Zeitpunkte durch regelmäßige Zeit signale eines Datenverarbeitungssystems definiert werden, wobei die Warteschlangenköpfe in Abhängigkeit von ihrer Ablaufzeit in einen List-Header einsortiert werden, wobei in einem ersten Bereich des List-Headers mit einer ersten Anzahl N1 von Warteschlangenköpfen jeweils einem von N1 aufeinander folgenden Zeitsignalen ein Warteschlangenkopf der ersten Anzahl von Warteschlangenköpfen zugeordnet wird und wobei in einem zweiten Bereich des List-Headers mit einer zweiten Anzahl N2 von Warteschlangenköpfen jedem Warteschlangenkopf der zweiten Anzahl von Warteschlangenkäpfen eine Warteschlange mit Software-Timern zugeordnet wird, deren Ablaufzeiten ein durch den Wert von N1 definiertes Zeitintervall überstreichen, dadurch gekennzeichnet, dass alle Software-Timer mit einer Ablaufzeit in einem Abstand von mehr als N1·N2 Zeitsignalen von einer aktuellen Zeit einer gemeinsamen Überlauf-Warteschlange zugeordnet werden.
Verfahren nach Anspruch 11, dadurch gekennzeichnet, dass eine Prüfung des List-Headers auf Timerablauf regelmäßig folgende Schritte beinhaltet: a) Abfragen eines aktuellen, durch das Zeitsignal adressierten Warteschlangenkopfes aus der ersten Anzahl von Warteschlangenköpfen, b) nach erfolgter Abfrage alle Warteschlangenköpfe aus der ersten Anzahl von Warteschlangenköpfen in Schritt a), Aufteilen einer aktuellen Warteschlange aus dem zweiten Bereich von Warteschlangenköpfen auf die Warteschlangen aus dem ersten Bereich von Warteschlangenköpfen in Abhängigkeit von der Ablaufzeit der jeweiligen Software-Timer, und c) nach erfolgter Aufteilung aller Warteschlangen aus der zweiten Anzahl von Warteschlangenköpfen in Schritt b), Aufteilen der Überlauf-Warteschlange auf die Warteschlangen aus dem ersten und zweiten Bereich von Warteschlan genköpfen und/oder auf die Überlauf-Warteschlange in Abhängigkeit von der Ablaufzeit der jeweiligen Software-Timer.
Datenverarbeitungssystem (1), aufweisend: – wenigstens eine Speichereinheit (4), – wenigstens eine Prozessoreinheit (3) in Wirkverbindung mit der Speichereinheit (4), und – in der Speichereinheit (4) gespeicherten ersten Programmcode (8.1), durch den bei Ausführung in der Prozessoreinheit (3) eine Gesamtmenge von Software-Timern (10.x) erzeugbar ist, gekennzeichnet durch in der Speichereinheit (4) gespeicherten zweiten Programmcode (8.2), durch den bei Ausführung in der Prozessoreinheit (3) ein Programmcode-Mechanismus (9.x) generierbar ist, der zum Aufteilen der Gesamtmenge von Software-Timern (10.x) in Teilmengen und zum Bearbeiten jeder Teilmenge auf einem jeweils festgelegten Prioritätsniveau (ISR, TASK) ausgebildet ist.
Datenverarbeitungssystem (1) nach Anspruch 13, gekennzeichnet durch einen weiteren Programmcode-Mechanismus (9.x), der zum Verwalten jeder Teilmenge von Software-Timern (10.x) durch einen zugeordneten List-Header (11.x) ausgebildet ist, wobei jeder Eintrag (Kx) in dem List-Header (11.x) den Warteschlangenkopf einer Warteschlange von Software-Timern (10.x) bildet, welche zu einem gemeinsamen Zeitpunkt (t) ablaufen.
Datenverarbeitungssystem (1) nach Anspruch 13 oder 14, gekennzeichnet durch einen weiteren Programmcode-Mechanismus (9.x), der zum Aufteilen der Software-Timer (10.x) in Abhängigkeit von einer Zeitkritizität der ih nen jeweils zugeordneten Anwendungen (CT, KT, ETT1, ETT2) ausgebildet ist.
Datenverarbeitungssystem (1) nach einem der Ansprüche 13 bis 15, gekennzeichnet durch einen weiteren Programmcode-Mechanismus (9.x), der zum Behandeln wenigstens einer ersten Teilmenge von Software-Timern (10.x) auf Echtzeit-Ebene (ISR) ausgebildet ist.
Datenverarbeitungssystem (1) nach einem der Ansprüche 13 bis 16, gekennzeichnet durch einen weiteren Programmcode-Mechanismus (9.x), der zum Behandeln wenigstens einer zweiten Teilmenge von Software-Timern (10.x) auf Task-Ebene (TASK) ausgebildet ist.
Datenverarbeitungssystem (1) nach Anspruch 17, gekennzeichnet durch einen weiteren Programmcode-Mechanismus (9.x), der zum Feststellen auf Echtzeit-Ebene (ISR) dahingehend ausgebildet ist, ob der zugeordnete List-Header (11.2, 11.4) der zweiten Teilmenge einer Bearbeitung bedarf, insbesondere wegen Ablauf wenigstens eines Software-Timers (10.x) oder einer erforderlichen Umsortierung wenigstens einer Warteschlange (OL).
Datenverarbeitungssystem (1) nach Anspruch 18, gekennzeichnet durch einen weiteren Programmcode-Mechanismus (9.x), der im Falle einer positiven Feststellung zum Bearbeiten des List-Headers (11.2, 11.4) ausgebildet ist, wobei die Bearbeitung durch einen höherprioren Task unterbrechbar ist.
Datenverarbeitungssystem nach einem der Ansprüche 14 bis 19, gekennzeichnet durch einen weiteren Programmcode-Mechanismus (9.x), der zum Sperren einer umzu sortierenden Warteschlange (OL) für einen Zugriff durch andere Anwendungen ausgebildet ist.
Datenverarbeitungssystem (1) nach einem der Ansprüche 14 bis 20, gekennzeichnet durch einen weiteren Programmcode-Mechanismus (9.x), der zum Anhängen einer umzusortierenden Warteschlange (OL) an einen ausgezeichneten Warteschlangenkopf (15) ausgebildet ist, sodass die Umsortierung von dort aus erfolgt.
Datenverarbeitungssystem (1) nach einem der Ansprüche 14 bis 21, gekennzeichnet durch einen weiteren Programmcode-Mechanismus (9.x), der bei Ablauf eines Software-Timers (10.x) aus einer nicht Echtzeit relevanten Teilmenge von Software-Timern zum Veranlassen eines Aufrufens eines betreffenden Timer-Handlers (9.8) durch dieselbe Trägertask (CT) ausgebildet ist, die für ein Verwalten der entsprechenden Teilmenge, insbesondere für die Bearbeitung des entsprechenden List-Headers (11.2), zuständig ist.
Datenverarbeitungssystem (1) nach dem Oberbegriff des Anspruchs 13, insbesondere mit weiteren Merkmalen der Ansprüche 13 bis 22, mit in der Speichereinheit (4) gespeichertem weiteren Programmcode (8.x), durch den bei Ausführung in der Prozessoreinheit ein Programmcode-Mechanismus (9.x) generierbar ist, der ausgebildet ist zum: – Einordnen aller zu einem gemeinsamen Zeitpunkt ablaufenden Software-Timer (10.x) in eine Warteschlange mit einem Warteschlangenkopf (Kx), wobei die Zeitpunkte durch regelmäßige Zeitsignale des Datenverarbeitungssystems (1, 12) definiert sind, – Einsortieren der Warteschlangenköpfe (Kx) in einen List-Header (11.x) in Abhängigkeit von ihrer Ablaufzeit (t), – Zuordnen eines Warteschlangenkopfes (Kx) aus einer ersten Anzahl N1 von Warteschlangenköpfen in einem ersten Bereich (11.xa) des List-Headers (11.x) zu jeweils einem von N1 aufeinander folgenden Zeitsignalen, und – Zuordnen jeweils einer Warteschlage mit Software-Timern, deren Ablaufzeiten ein durch den Wert von N1 definiertes Zeitintervall überstreichen, zu Warteschlangenköpfen (Kx) aus einer zweiten Anzahl N2 von Warteschlangenköpfen in einem zweiten Bereich (11.xb) des List-Headers (11.x), dadurch gekennzeichnet, dass der Programmcode-Mechanismus (8.x) zum Zuordnen aller Software-Timer (10.x) mit einer Ablaufzeit (t) in einem Abstand von mehr als N1·N2 Zeitsignalen von einer aktuellen Zeit zu einer gemeinsamen Überlauf-Warteschlange (OL) ausgebildet ist.
Datenverarbeitungssystem (1) nach Anspruch 23, dadurch gekennzeichnet, dass der Programmcode-Mechanismus (8.x) zum Durchführen einer Prüfung des List-Headers (11.x) auf Timerablauf ausgebildet ist, die regelmäßig folgende Schritte beinhaltet: a) Abfragen eines aktuellen, durch das Zeitsignal adressierten Warteschlangenkopfes (Kx) aus der ersten Anzahl von Warteschlangenköpfen, b) nach erfolgter Abfrage alle Warteschlangenköpfe (Kx) aus der ersten Anzahl von Warteschlangenköpfen (Kx) in Schritt a), Aufteilen einer aktuellen Warteschlange aus dem zweiten Bereich (11.xb) von Warteschlangenköpfen (Kx) auf die Warteschlangen aus dem ersten Bereich (11.xa) von Warteschlangenköpfen in Abhängigkeit von der Ablaufzeit (t) der jeweiligen Software-Timer (10.x), und c) nach erfolgter Aufteilung aller Warteschlangen aus der zweiten Anzahl von Warteschlangenköpfen (Kx) in Schritt b), Aufteilen der Überlauf-Warteschlange (OL) auf die Warteschlangen aus dem ersten (11.xa) und zweiten Bereich (11.xb) von Warteschlangenköpfen (Kx) und/oder auf die Überlauf-Warteschlange (OL) in Abhängigkeit von der Ablaufzeit (t) der jeweiligen Software-Timer (10.x).
Computerprogrammprodukt, dadurch gekennzeichnet, dass ein Verfahren nach einem der Ansprüche 1 bis 12 durchführbar ist, wenn das Computerprogrammprodukt auf einer Datenverarbeitungsanlage ausgeführt wird.
Verwendung eines Datenverarbeitungssystems (1) nach einem der Ansprüche 13 bis 24 für die Steuerung einer Anlage (5) mit einer Anzahl von Automatisierungseinheiten (6.1-6.3).