Parallele Datenaufnahme, Erz-Verbr verbraucht irgendwann nicht mehr

hier mal ein kleines Update:

Viel hat sich nicht verändert, und manche Probleme bestehen immer noch.

Die Waittime ausm Consumer wurde rausgeworfen, DBL wird direkt in die Queue eingespeist, unnötige Lokale Variablen wurden entfernt (s. Anhang).

Bislang ist es nicht passiert, dass der Consumer einfach nicht mehr gearbeitet hat, selbst wenn ein neues Element in die Queue gesetzt wurde. Schonmal gut.


Was immernoch passiert, ist, dass die Motorsteuerung stockt, wenn irgendwas gemacht wird. Es dauert anscheinend recht lange, die aktuelle Motorposition an die Queue weiterzugeben (währenddessen kann der Motor nicht weiter), aber noch mehr stockt er, wenn der Consumer läuft.

Liegt es am (für heutige Verhältnisse) lahmen PC (2,4GHz Celeron, 2GB Ram) oder kann man das irgendwie beheben?
Eine wirklich parallele Abarbeitung (mit höchster Prio beim Producer) wäre wirklich wünschenswert. Gibts da eine Alternative zum Producer-Consumer-Design?


Kurz noch zum Consumer (s. Screenshot):
Nach meinem Empfinden sollte er die gesamten (alten) Messdaten aus Values1.txt lesen, pro Schleifendurchgang je einen Teilstring anhängen und bei Beenden der Schleife den gesamten String wieder in Values1.txt abspeichern. Tut er aber nicht. Starte ich das Programm mit aktivierten Stopschaltern, speichert er (für den einen Durchlauf) die Messdaten ab, lasse ich jedoch das Programm einfach laufen und beende dann nach ein paar Durchgängen über (beide) Stop-Schalter, speichert er NICHTS ab.

Was geht, ist in jedem Durchgang einen String in Values2.txt abzuspeichern. Er wird dadurch nicht spürbar langsamer (er IST es ja schon ), aber wirklich elegant finde ich das nicht.

Jemand ne Idee?