Hallo,

ich habe eine Frage zur Programmstrukturierung.
Folgendes Szenario:

Es gibt einen Thread der 30 mal in der Sekunde Daten liefert, diese Daten werden 100ms (3 Zyklen)später auf der GUI ausgegeben.
Jetzt sollen diese Daten aber noch zwischenverarbeitet werden. Für die Bearbeitung ist ein Zyklus zu kurz.

Meine Idee: Die Bearbeitung wird mittels einens Threadpools gemacht, dadurch kann ich die vollen 3 Zyklen zum Bearbeiten nutzen.

Was meint ihr?

Die Daten werden in einem Array gespeichert.

Ich wäre über viele Antworten dankbar.

Viele Grüße
Bastel

Gibt es im C# nicht auch sowas, wie eine TQueue? (für die Zwischenspeicherung)
Diese müßte man eventuell nur noch etwas threadsicher machen.

Aber ich komm rein rechnerisch nicht ganz klar.
Es kommen immer wieder neue Daten an, die Verarbeitng der Daten dauer länger, als die Zeit bis die nächsten Daten eintreffen.

Irgendwie bekomm ich da das Gefühl, als wenn da etwas nicht ganz aufgeht.
Selbst wenn man die Verarbeitung in einen anderen thread auslagert, wird er dennoch nicht hinterherkommen.
Auch mehrere Threads werden nicht ganz klappen, außer daß der Verarbeitungsdurchsatz irgendwann zuviel wird ... je mehr CPUs, um so mehr Sekunden hält das Ganze durch, aber nach spätestens einigen Sekunden ist dann alles so überlastet, das garnichts mehr geht.

Ja in C# gibt es eine TQueue, was mich hier aber nicht weiterbringt.

Ich dachte mir das so: Wenn ein neuer Datensatz, der noch nicht berechnet ist ankommt, einen Thread aus dem Threadpool bekommt, der in dann berechnte. Nach 3 Zyklen ist das dann berechnet und der Thread wieder frei.
So laufen also maximal 3 Verarbeitungsthreads parallel.

Oder denke ich da falsch?

OT ein

Multithreating = Mehrfacher Schadcode???
Multithreading = Mehrere parallele Ausführungstasks

OT aus

Langsam glaube ich, dass schreibt man heutzutage so
http://www.delphipraxis.net/167985-s...-new-post.html

Zitat von sebi87:

Hallo,

ich habe eine Frage zur Programmstrukturierung.
Folgendes Szenario:

Es gibt einen Thread der 30 mal in der Sekunde Daten liefert, diese Daten werden 100ms (3 Zyklen)später auf der GUI ausgegeben.
Jetzt sollen diese Daten aber noch zwischenverarbeitet werden. Für die Bearbeitung ist ein Zyklus zu kurz.

Falls die CPU der Flaschenhals ist, hast du dann ein Problem. Denn mit Threads erhöht sich ja nicht automatisch die Berechnungsgeschwindigkeit. Vielmehr werden dann zwei Sachen gemacht, von denen dann aber beide nur halb so schnell gehen. Falls du eine Dual- oder Quad-Core CPU vorraussetzen kannst, kannst du mit Threads schon doppelt bzw. viermal so schnell arbeiten. Dann bleibt aber das Problem auf Rechnern mit einem Kern. Und alte Quadcores schaffen auch nicht die Rechenleistung von neueren.

Ist eine Auswertung parallel zur Erfassung der Daten notwendig? Kann man vielleicht den Algorithmus noch optimieren?

P.S.: C# hat zwar eine Queue, aber es gibt auch einen Threadpool ( http://msdn.microsoft.com/de-de/libr...(v=vs.80).aspx ) der für solche Aufgaben wie geschaffen ist.
Beim Threadpool kannst du auch die maximale Anzahl an Threads festlegen wenn du möchtest, aber er wird keine Aufgabe überspringen. Falls die CPU also zu langsam ist, hinkt die Auswertung irgendwann ziemlich weit hinterher.

Wenn ich alle X ms neue Daten bekomme, deren Verarbeitung y ms benötigt, dann brauche ich mindestens trunc(0.5+y/x) Kerne. Hier wären das 3. Ist ja klar, denn bei weniger Kernen kommt vorne mehr rein als hinten raus. Damit benötige ich auch 3 Threads, eventuell einen mehr, wegen des Overheads.

Die Queue muss also mindestens so viele Datensätze vorhalten, wie es Threads gibt.

Damit kann man bei einem Queue-überlauf sofort abbrechen, denn die Hardware, auf dem die Anwendung läuft, wird das nicht packen.

Wenn alle Daten bereits in einem Array vorliegen, solltest Du dir PLINQ anschauen, weil damit das ganze Threadgedöns komplett von C# übernommen wird.