2012-04-05 4 views
1

In Xenomai's API of Posix skin finde ich folgendes:Welcher Code sollte NICHT in Echtzeit geschrieben werden?

POSIX Haut.
Dienstleistungen von Uhren und Zeitschaltuhren.
Bedingungsvariablen-Dienste.
Unterbrechungsmanagementdienste.
Message Queues-Dienste.
Mutex-Dienste.
Semaphore Dienstleistungen.
Shared Memory-Dienste.
Signale Dienste.
Threads Management Services.
Thread-Löschung.
Threads Scheduling-Dienste.
Thread-Erstellungsattribute.
Threadspezifische Daten.

Ich kann nichts über die Datei Handhabung und Socket-Programmierung finden Sie so Ich vermute, dass vielleicht Handling-Datei und Steckdosen in der Echtzeit behandelt werden nicht werden? Ist die Schätzung falsch?

Bitte führen.

Antwort

4

Xenomai und sein Ursprung, RTAI, übernehmen die Kontrolle über Ihren Scheduler und behandeln den Linux-Kernel selbst als Nicht-Echtzeit-Thread.

Sie haben viele Dienste zur Verfügung gestellt, von denen die meisten, wie Sie sehen können, mit Threads und Synchronization zusammenhängen, die Linux API (im Kernelraum) oder Systemaufrufe (im Benutzerbereich) NICHT aufrufen. Wie Sie wissen, dreht sich in Echtzeit alles um "garantierte Deadline" und der Aufruf von Linux verletzt es (weil Linux nichts garantiert).

Da Treiber auch in Echtzeitsystemen wichtig sind, haben sie das Echtzeittreibermodell RTDM implementiert, das sowohl die Implementierung als auch die Verwendung von Gerätetreibern in Echtzeit unterstützt.

Das Dateihandling im Kernel ist sehr verpönt. Wenn Sie über Benutzer-Space-Echtzeitanwendungen sprechen, können Sie auf alle Treiber zugreifen, die in RTDM implementiert sind. Wenn Sie keine Dateiverwaltung oder Sockets finden, können Sie sie nicht verwenden. Beachten Sie, dass selbst eine printf Linux-Systemaufrufe verwendet und verboten ist.

Beachten Sie, dass, wenn Sie sie verwenden, nichts bricht, verlieren Sie nur Ihre Echtzeitfähigkeit! Ich persönlich benutze Dateien für die Protokollierung, aber rufe sie nur im Falle eines Fehlers auf, der bedeutet, dass die Echtzeit ohnehin schon ruiniert ist.

Ich weiß nicht über Xenomai, aber zumindest in RTAI, wenn Sie einen Linux-Systemaufruf aufrufen, dann erhalten Sie eine Warnung wie "RTAI: LXRT geändert Modus: syscall ..." in Ihren Kernel-Logs.

+0

Das ist sehr hilfreich. Vielen Dank. Kannst du mich auf einen Link verweisen, der in Echtzeit über Dos und Don'ts spricht, außer was Xenomai sagt? –

+0

@AnnishaKaul, lass mich suchen. Leider gibt es nicht viele Echtzeitanwendungen/Benutzer für eine breite Palette von Informationen, die im Internet verfügbar sind. – Shahbaz

+0

Ja, das ist das Problem. Bitte, wenn Sie hier etwas Link finden. Vielen Dank. –

1

Die Echtzeit ist eine Eigenschaft des GESAMTEN SYSTEMS. Um die Echtzeiteigenschaft im System zu erreichen, sollten alle Komponenten (einschließlich Hardware, Betriebssystem, Treiber, Bibliotheken und Anwendungen) unter Berücksichtigung der Anforderungen an Echtzeitsysteme entworfen werden. Solche Komponenten (wie RTOS) können verwendet werden, um ein Echtzeitsystem aufzubauen. Aber ihre Verwendung bedeutet nicht automatisch, dass das endgültige System ein Echtzeitsystem sein wird. Wenn mindestens eine der Komponenten Ihres Systems die Anforderungen von Echtzeitsystemen nicht unterstützt, ist Ihr gesamtes System nicht in Echtzeit!

Echtzeitsysteme haben normalerweise Ressourcen, die die durchschnittlichen Anforderungen der Echtzeitaufgaben deutlich übersteigen. Unverbrauchte Ressourcen können für die Ausführung nützlicher, aber nicht kritischer Hintergrundaufgaben wie Protokollierung, Überwachung des Systemstatus, Statistikerfassung und -analyse usw. verwendet werden. Anwendungen, die diese Aufgaben ausführen, können als nicht echtzeitfähige Komponenten ausgeführt werden von Echtzeitkomponenten. Dieses Design ist sicher, wenn Sie sicher sind, dass alle Komponenten, die an Echtzeitaufgaben teilnehmen, Echtzeitanforderungen unterstützen. Aufgrund dieser direkten Antwort auf Ihre Frage:

Es hängt vollständig von der Anwendung ab. Im Allgemeinen kann der gesamte Code, der nicht zur Verarbeitung von Echtzeitaufgaben verwendet wird, als Nicht-Echtzeit geschrieben werden. Der gesamte Code, der bei der Verarbeitung von Echtzeitaufgaben verwendet wird, MUSS als Echtzeit geschrieben werden.

Was die Xenomai macht, ist die Isolierung des Nicht-Echtzeit-Linux und verwendete seine Aktivitäten für die Handhabung von Nicht-Echtzeit-Aufgaben in dem speziellen Behälter, der oben auf dem RTOS-Kernel ausgeführt wird und parallel zu RTOS Echtzeit-Aufgaben. Um ein Echtzeitsystem auf den Xenomai-Basen aufzubauen, sollte sich Ihre Anwendung nur auf die Xenomai-API und auf die anderen Bibliotheken und APIs stützen, die bekannt sind und sich in Echtzeit bewährt haben. Alle Hintergrundaktivitäten, die nützlich, aber völlig unkritisch sind, können als ordinale Linux-Anwendungen geschrieben werden.

Solche Systeme und Dienste wie Speicher- und Netzwerkdienste werden normalerweise nicht in Echtzeitaufgaben verwendet, da die häufig verwendete Hardware sehr indeterministisch ist und daher nicht gut in das Echtzeitkonzept passt. Es ist schwer zu sagen, wie lange es dauert, fünf Pakete über das Netzwerk zu senden oder eine Datei auf die Festplatte zu schreiben. Aus diesem Grund sind Schnittstellen für solche Systeme nicht alltäglich. Aber wieder, die Anwendung diktiert, welche Echtzeit-Dienste es benötigt. Ich kann mir Echtzeit-Aufgaben vorstellen, die Speicher- und Netzwerkaktionen beinhalten. Bei solchen Aufgaben ist der Designer gezwungen, solche Systemkomponenten zu finden, die Echtzeitspeicher- und Netzwerkdienste bereitstellen. Wie Sie sehen können, ist Xenomai kein Kandidat.