Echtzeitanwendung - Welche Struktur beim Dateizugriff?

[Matze]

Hi zusammen,

auch wenn ich vermute, dass die meisten von euch von Echtzeitsystemen keine Ahnung haben, versuche ich dennoch mein Glück. Ich hoffe, ihr könnt mir folgen.
Ich erfasse sehr viele Messwerte und muss dieses auswerten und speichern.
.
Aktuell habe ich eine Schleife, in der Datenerfassung, Auswertung und Protokollierung erfolgen. Die Messdaten werden teils parallel, teils nacheinander eingelesen.

Aktuell habe ich das in der Schleife sequenziell so aufgebaut. Ihr müsst euch vorstellen, dass die Schleife pro Messung mehrmals durchlaufen wird:

1. Datenerfassung aller Sensoren (Daten werden gepuffert und z.B. alls 100 ms 100 Werte ausgelesen)
2. Prüfen, welche Daten relevant sind bzw. welche Sensoren auszuwerten sind
3. Pufferung der relevanten Messwerte
4. Messzeit abwarten
5. Wenn Messzeit(en) abgelaufen, Daten speichern (binär, also nicht im ASCII-Format o.ä.)
6. Schleife von vorne beginnen und erneut prüfen, ob das Messende vorliegt, eine neue Messung beginnen soll o.ä.

Es kann folgendes sein: Messzeit 5 Sekunden
Und z.B. nach 1 Sekunde beginnt die Messung von Sensor 1, nach 2 weiteren Seunden die von Sensor 2. Wenn die Messung von Sensor 1 dann zu Ende ist und die Daten protokolliert werden, läuft die Messung von Sensor 2 noch weitere 3 Sekunden und wird dann protokolliert. In der Zeit kann aber die Messung von Sensor 1 wieder beginnen.

Mein Problem ist nun, dass das Speichern der Datei sehr lange dauert (ca. 100 - 500 ms), selbst bei einer Dateigröße von 300 Bytes.
Die Messwerte werden zwar gepuffert und gehen auch bei Verzögerungen nicht verloren, aber die Messzeit variiert, da aufgrund der Verzögerungen der Schleifendurchlauf stark variieren kann.

Nun dachte ich mir, ich nehme eine Schleife für Erfassung und Bewertung (deteministisch) und eine parallele While-Schleife, die die Protokollierung übernimmt. Ich habe übrigens eine Single-Core-CPU.
In der Erfassungs-Schleife (höchste Priorität) würde ich z.B. alls 100 ms meine Messwerte auslesen und dann auswerten. In der Zeit, in der auf die Messwerte gewartet wird, könnten eventuelle Speichervorgänge in der parallelen Schleife durchgeführt werden.

Die CPU würde vermutlich in der Wartezeit der Erfassungs-Schleife die parallele Speichern-Schleife abarbeiten, sofern ich dieser Daten übergebe.

Ich hoffe, ihr konntet mir nun halbwegs folgen.
Habt ihr 'ne Ahnung, ob dieses Vorgehen sinnvoll ist der kennt ihr Alternativen?

Grüße
Matze

[divBy0]

Single-Core ist etwas doof, aber vielleicht kannst du die Daten in der Messschleife ja als Memorystreams im Speicher halten und unabhängig von der Messschleife in einem Thread abspeichern.

Bei jeder Messung erzeugst du einen neuen Memorystream in einer Liste und die Liste müsste sich ja abarbeiten lassen.

Welches System wird genutzt? VxWorks? Win?

[Matze]

Hallo Marc

Zitat von divBy0:

Single-Core ist etwas doof ...

Stimmt, aber aus Kostengründen das einzig mögliche.

Zitat von divBy0:

Welches System wird genutzt? VxWorks? Win?

Wow, du kennst dich aus. Es ist in der Tat VxWorks.

Mir geht es da ganz allg. um ein sinnvolles Vorgehen, sprachunabhängig. Und Memorystreams würden mir nicht helfen, denn sobald ich den speichere, habe ich genau den gleichen Dateizugriff.
Die Daten habe ich in Variablen schon aufbereitet. Nur wie sie gespeichert werden können, weiß ich noch nicht.

[sx2008]

Jeweils ein Thread pro Sensor.
Diese Thread dürften die meiste Zeit am Schlafen sein, weil sie auf das Eintreffen der Sensordaten warten.
Danach werden die Meßwerte verpackt (als binärer Datenblock) und in die Queue geschoben.

Die Threads bekommen schon mit dem Erzeugen eine (threadsichere) Queue mitgegeben.

Ein weiterer Thread prüft, ob die Queue gefüllt ist, entnimmt die Daten und schreibt sie in eine Datei (oder einen Stream).

[Matze]

Hallo,

mehrere Threads bringen in meinem Falle nichts. Bei einer Single-Core-CPU wird ja alles nacheinander ausgeführt, d.h. ich habe mir Funktionen geschrieben, die in einer For-Schleife meine Sensoren durchgehen und diverse Dinge berechnen etc.

Das funktioniert soweit auch alles.

Nur das Speichern bereitet mir zur zeit Probleme. Daher dachte ich daran, dieses Teil in einen separaten Thread auszulagern.

Das ganze ich deutlich komplexer als ich es bisher dergestellt habe. Ich bekomme übers Netzwerk Daten wie z.B. ein Boolsches Array. Index 0 enspricht Sensor 1, ...
Und das Array kann ich innerhalb einer einzigen For-Schleife sehr leicht verarbeiten (Schleifen-Index = Array-Index). Daher möchte ich die Erfassung und Auswertung in einer einzigen Schleife machen.

[Sir Rufo]

trotz Single-CPU würde ich pro Empfangskanal auch einen Thread erzeugen.

Die meisten Threads werden ja eh schlafen, aber so braucht keiner der Empfangskanäle warten, bis dieser in der for-Schleife abgefragt wird.

Diese Threads würde ich auch NUR zum Erfassen der Daten benutzen. Die Auswertung der Daten ist ja dann nicht mehr zeitkritisch, da beim Empfang ja alle Parameter erfasst wurden (Messwert, Zeitpunkt der Messung)

Single-Core und Multi-Threading:

Es ist sicher richtig, wenn ich auf einem System mit n Kernen sehr rechenintensive Vorgänge in m Threads packe und m>n, dass die Performance nicht steigt, sondern sogar sinkt.
Hier haben wir aber nicht solch einen Fall, denn hier wartet jeder Thread eine ungewisse Zeit und somit sollte für jeden Thread genug Zeit da sein.

Wenn dem nicht so ist, dann ist auch die Single-Thread-Lösung ein nicht gangbarer Weg.

[Assarbad]

Zitat von Matze:

Hallo,

mehrere Threads bringen in meinem Falle nichts. Bei einer Single-Core-CPU wird ja alles nacheinander ausgeführt, d.h. ich habe mir Funktionen geschrieben, die in einer For-Schleife meine Sensoren durchgehen und diverse Dinge berechnen etc.

Das ist ein Irrtum. Selbst auf einem Einkern-System bieten Threads eine bessere Granularität bei der Ausführung. Zugegeben, irgendwann wird auch der Overhead zu groß, aber das dauert ne Weile.

Aber mal ne Frage. Müssen denn die Daten immer sofort geschrieben werden? Oder ginge sammeln und dann schreiben aus einem dedizierten Thread?

[mkinzler]

Sonst würde Intel ja auch nicht auf Hyperthreading setzen

[Sir Rufo]

Zitat von mkinzler;:

Sonst würde Intel ja auch nicht auf Hyperthreading setzen

Und wozu gebe es sonst das TThread-Objekt, wenn es nur interessant für Multi-Cores wäre.
Den Einwand, es gibt ja auch schon lange Multi-Cores, kontere ich mit es gibt aber auch schon 64Bit Systeme nur für Delphi nicht

[Assarbad]

Zitat von Sir Rufo:

Den Einwand, es gibt ja auch schon lange Multi-Cores, kontere ich mit es gibt aber auch schon 64Bit Systeme nur für Delphi nicht

Ich glaube ja HT ist einfach nur billiger