zwei Schleifen oder eine Schleife

(20.02.2013 23:59 )Hasenfuss schrieb:  Ich habe ein Problem, wo ich grade etwas auf dem Schlauch stehe.

Hallo Hasenfuss,

warum steht hier im Forum eigentlich jeder 2. Fragesteller auf dem Schlauch oder sieht den Wald vor lauter Bäumen nicht?!
Du und dein Chef habt euch doch dezidierte Gedanken über die o.a. Fragestellung gemacht und somit lediglich das Dilemma, dass jeder einen anderen Standpunkt vertritt - etwas mehr Selbstbewusstsein!

Nun aber zum eigentlichen Problem, das aus reichlich Lesetext besteht

Ich würde, ohne deine Systemanforderungen genau zu kennen, grundsätzlich auch dazu raten, eine Producer / Consumer - Struktur aufzubauen. Du schreibst, das Echtzeitsystem hat einen sehr großen Ringspeicher. Sehr ist meist sehr relativ - ich denke mal, der PC-Speicher wird größer sein. Da beim Speichern in eine Datei schonmal recht große OS-bedingte Verzögerungen auftreten können, sehe ich die Gefahr des Overrun beim Ringspeicher des Senders als deutlich größer an, als dass die Queue "überlaufen" würde.
Das Auf- und Zugemache der Datei ist sicher in beiden Fällen kein Problem, da man die Datei beim Prozessstart erstellen / öffnen und dann auf die Dateireferenz arbeiten würde. Ein PC-Absturz wäre hier auch nicht problematisch.
Die Zeitverzögerung durch das Senden der Daten an die Consumerschleife ist in bezug auf die Zeiten, die das Speichern der Daten dauert so marginal, dass sie vernachlässigbar ist.

Die Frage ist im Grunde, von welchen Datenfluten wir hier reden. Werden ein paar tausend byte pro Sekunde gesendet, kann man sich die Zweischleiferei sicher sparen - reden wir aber von Daten im ms-Bereich, würde ich den Queue-Puffer schon dazwischennehmen. Im übrigen gibt es auch TCP-Sendesysteme, die ihre TCP-Verbindung abbauen, wenn sie ihre Daten nicht loswerden - dann hättest du ein noch größeres Problem. Schon deshalb sollte das Auslesen der Schnittstelle mit hoher Priorität parallel erfolgen.


Gruß, Marko