vector Threadsave read/write
-
BorisDieKlinge schrieb:
ich weis was ne queue ist , aber ich weis nich was die mir nutzen soll^^ Der Thread fügt records an die liste hinzu egal ob die Grafik die list derweil liest und zeichnet. solange sie nur bist zu dem element der list liest, wo der thread nichts machts...
WEil ich die die elemente der list ja nicht mehr rauschmeise, was drin ist ist drin;) das diagramm soll nur die letzen X elemente anzeigen;)
Ich verstehe den Post nichtmal im Ansatz. Probier mal die Shift-Taste aus...
-
---------------------- thread List: <1> <2> <3> <4> <5> ---------------------- ---------------------- UI grahic referen auf list un iterator auf <1> und <5> ---------------------der thread fügt jetzt ein neues element an <6>
die UI zeichnet die kurven von <1> bis <5>
die kurve muss also nicht UNBEDING Syncron im takt wie der thread die punkte zeichen...die List im thread wird gleichzeitig in ne datei gespeichert..
-
Da wäre ne Queue perfekt...
Die Nichtsynchronität ist doch gerade der Sinn der Queue. Die entkoppelt den Producer vom Consumer.
Der Rekorder packt einfach immer was rein. Egel wie er gerade lustig ist. Der Zeichner nimmt einfach was raus, so schnell er kann.
Wenn der Zeichner schneller ist als der Rekorder, läuft die Queue leer. Der Zeichner muss warten, bis wieder was zum Zeichnen da ist.
Wenn der Rekorder schneller ist als der Zeichner füllt sich die Queue langsam bis der Rekorder fertig ist.
Da ist nichts synchron. Der Zeichner versucht zu zeichnen, wenn er es möchte, und der Rokorder packt was rein, wenn er möchte.
Und es gibt auch nur eine Queue. Der eine packt was rein, der andere nimmt was raus.
-
wo werden die daten dann gespeichert?? wenn der thread sie in die queue gibt, und das diagamm sie abholt? ich will die aufgezeichneten daten später wieder anschaun kkönnen, in dem ich die datensätze lade...
-
Der Rekorder kann doch direkt jeden aufgezeichneten Datensatz gleichzeitig zum in die Queue packen auch wegspeichern. Wieso muss es dafür erst in einer Liste stehen?
-
Hm, dazu gleich noch eine Frage...
Selbst wenn man die Queue mittels zB einer CriticalSection Thread-Safe macht, könnte das zu Problemem führen. So weit ich weiß, darf immer nur der Prozess, der Objekte erzeugt hat, diese auch wieder löschen. Wenn aber nun der Producer die Daten in die Queue schreibt und der Consumter sie ausliest, werden die Objekte vom Producer erzeugt, aber vom Consumer gelöscht. Und genau das könnte ein Problem mit der Speicherverwaltung geben, oder nicht?
-
Joe_M. schrieb:
Hm, dazu gleich noch eine Frage...
Selbst wenn man die Queue mittels zB einer CriticalSection Thread-Safe macht, könnte das zu Problemem führen. So weit ich weiß, darf immer nur der Prozess, der Objekte erzeugt hat, diese auch wieder löschen. Wenn aber nun der Producer die Daten in die Queue schreibt und der Consumter sie ausliest, werden die Objekte vom Producer erzeugt, aber vom Consumer gelöscht. Und genau das könnte ein Problem mit der Speicherverwaltung geben, oder nicht?
Hmm, wenn dem so wäre, dann würden aber alle Pipes die so benutzt werden nicht gehen.
Hast Du mal eine Referenz, wo das steht? Würde mich mal interessieren.
-
Tachyon schrieb:
Hast Du mal eine Referenz, wo das steht? Würde mich mal interessieren.
Ich hatte gehofft, ihr könntet mir eine entsprechende Referenz geben.
-
Joe_M. schrieb:
Tachyon schrieb:
Hast Du mal eine Referenz, wo das steht? Würde mich mal interessieren.
Ich hatte gehofft, ihr könntet mir eine entsprechende Referenz geben.
camper?
-
Joe_M. schrieb:
Hm, dazu gleich noch eine Frage...
Selbst wenn man die Queue mittels zB einer CriticalSection Thread-Safe macht, könnte das zu Problemem führen. So weit ich weiß, darf immer nur der Prozess, der Objekte erzeugt hat, diese auch wieder löschen. Wenn aber nun der Producer die Daten in die Queue schreibt und der Consumter sie ausliest, werden die Objekte vom Producer erzeugt, aber vom Consumer gelöscht. Und genau das könnte ein Problem mit der Speicherverwaltung geben, oder nicht?
Im Prinzip ist das möglich. Wenn ich es richtig verstanden habe, soll es hier allerdings um verschiedene Threads in einem Prozess gehen. Ob ein Speicherblock, der in einem Thread angefordert wurde, in einem anderen Thread freigegeben werden darf oder nicht, hängt letztlich von der Implementierung der Speicherverwaltung ab. Es wäre denkbar, dass die Speicherverwaltung jedem Thread lokale Blöcke zuteilt, innerhalb deren keine Synchronisation erforderlich ist. In diesem Fall müsste man wohl die Speicherblöcke, die beim Consumer ankommen wieder zum Producer zurückbefördern (z.B. über eine Queue, bei der beide Rollen vertauscht sind). Andererseits ist das - üblicherweise - kein Problem mit den Standardfunktionen (new/delete, malloc/free etc.).