Java - Frage wg. Programmentwurf

[shedepe]

Mit einem STM32 würde ich direkt USB Bulk Transfers machen.
Außerdem wollte ich nicht sagen dass du keine 1-2 MBauds schaffst, sondern dass häufig mit geringeren Geschwindigkeiten geabeitet wird.

Welche API du hast habe ich keine Ahnung. Jede Serielport Implementierung die ich bisher gesehen habe (C/C++/C#/Python) ermöglicht es einem eine Abfrage zu machen: Wie viele Bytes sind da? und dann lies n-Bytes am Stück aufzurufen.

Letztendlich ist es ja genau das was du willst. Schauen wie viele Bytes sind da. Wenn deine API das nicht zulässt würde ich dir vorschlagen eine andere Implementierung zu suchen. In wirklich kurzen Zeitintervallen regelmäßig etwas zu machen ist auf einem normalen Desktoptechner nicht machbar allein scho nwegen des Schedulers.

[White_Fox]

Wie gesagt, von dem USB-Kram hab ich keine Ahnung. Damit befasse ich mich vielleicht später mal...

Die API die ich hab bietet zwar normale Lese- und Schreibmethoden, aber auch Observer-Benachrichtigung, und die benutze ich.

Schade...keine Java-Programmierer hier? Dabei ist die Sprache klasse, wie ich finde.

[shedepe]

Wie gesagt. Ich bin kein Java Programmierer, bin aber der Ansicht, dass die Sprache im Endeffekt recht egal ist. Ein Serialport bleibt ein Serielport egal ob man in C, Java oder Brainfuck anspricht. Manche Sprachen bauen Wrapper drumherum, die manchmal Sinn machen zu verwenden, manchmal auch nicht.

Nun lass uns deine Aufgabenstellung zerlegen. Du willst zum Einen das Observer Pattern verwenden, also benachrichtigt werden wenn neue Daten ankommen.
Die ersten Fragen die sich an dieser Stelle stellen:
1. In welchem Thread wird dieser Aufruf durchgeführt (main Thread, eigener Thread ?)
2. Wirst du für jedes Byte oder nur einen Satz an Bytes benachrichtigt -> Allgemein welche Informationen bekommst du an dieser Stelle

Diese Informationen können einem später weiterhelfen zu entscheiden ob ein extra Thread überhaupt Sinn macht.

Nun kommen wir weiter zu deiner Anforderung bzw. deinem ersten Vorschlag.
Du hast vorgeschlagen in einer Endlosschleife die Daten abzuprüfen. Hast du dir denn schon überlegt wie du die Daten an diese Stelle hinbekommst? (Ich habe dir an der Stelle einen recht klassischen Polling Ansatz beschrieben, deine Library oder das Betriebssystem macht untendrunter auch nichts anderes, wobei das Betriebssystem aber noch am ehesten die Möglichkeit hätte einen Interrupt basierten Ansatz umzusetzen)

Wenn du deinen Ansatz so verfolgen willst, wirst du nicht darum kommen die Daten selber zwischen zu speichern und zwar in einer Form, dass du gefahrlos aus zwei Threads darauf zugreifen kannst. Letztendlich hättest du dabei aber nur einen weiteren Zwischenspeicher eingeführt (eben in deiner eigenen Anwendung statt in der Seriallib bzw. im Betriebssystem)

Welche Schlüsse kann man daraus ziehen (bzw. die ich daraus ziehen würde): Wenn man den Event basierten Ansatz (also Observerpattern) verwenden willst, ist es meiner Ansicht nach am sinnvollsten direkt an der Stelle wo man benachrichtigt wird seine Bytes zu verarbeiten.

Wenn man einen extra Thread verwenden will ist es am sinnvollsten die Daten selber abzuholen. Wenn du das richtig machst, kannst du dir (nachdem was du beschrieben hast) eventuell sorgar teilweise sparen die Daten zu holen sondern musst nur abfragen wie viele Bytes gerade da sind.

Sollte man wirklich (auch dafür kann es gute Gründe geben) beide Ansätze kombinieren wollen, dann ist es das Sinnvollste eine Thread sichere Queue zu verwenden , dort von der Stelle wo man benachrichtigt wird welche Daten ankommen die Daten reinzuschreiben und in dem extra Thread die Daten aus der Queue zu holen und zu verarbeiten.

Welche Variante man davon verwendet ist meiner Ansicht nach, bei den Datenmengen die über eine Serielleverbindung laufen egal. Die Daten direkt in einem extra Thread zu holen hat meiner Erfahrung nach die geringste Latenz.

[Ceos]

Ich will den Thread nicht 1ms (weniger geht anscheinend nicht) schlafen legen, das erscheint mir doch ein wenig viel. Allerdings muß der Thread im Leerlauf auch nicht die CPU voll auslasten.

Thread.yield()

oder

try{
   Thread.sleep(x);
} catch (InterruptedException ignore) {
}

zuerst einmal Thread.yield() das Allheilmittel gegen 100% CPU in einem Task der ohne Sleep arbeitet!

to yield | yielded, yielded |

nachgeben | gab nach, nachgegeben

Das bedeutet, dass der Task der gerade diesen Aufruf macht, dem System anbietet "Ich könnte jetzt Pause machen wenn du gerade etwas anderes zu tun hast"
Du hast keine 100% Auslastung, das ist ein Missverständniss, du hast 100% blockiert, weil du niemals Pause machst, sondern selbst das Abrufen eines leeren COM Port ohne unterlass wiederholst ohne dem System (oder dem CPU Core) die Möglichkeit zu geben auch mal andere Arbeiten auszuführen

Und das zweite was du bei einem Sleep beachten solltest, ein Sleep ist nicht zwangsläufig ununterbrechbar! Ein Sleep kann jedezeit utnerbrochen werden ohne dass die Daten verloren gehen, solange dein Input die MÖglichkeit hat deinen Schlafenden Thread zu wecken (Interrupt). Wie du deinen COM Port allerdings dazu bringst das Sleep zu Interrupten (Deswegen auch der Try-Catch-Block im Beispiel) müsstst du selber mal herausfinden, dafür efhlen mir zu viele Inofs

[White_Fox]

Ah...danke für die Erklärung der yield()-Methode. Ich hab da kurz was drüber gelesen, war mir aber nicht so sicher dabei. Ich denk das werd ich dann damit machen.

Und gut zu wissen daß auch die sleep()-Methode unterbrochen werden kann...