ich habe ein Datarecorder.. dieser läuft in einem eigenen Thread und fügt in einem best. Intervall datensätze an einen/mehrere std::vectoren. Bei jedem Iternvall schickt der Thread eine event "Neue Datensatz" an ein fenster.
In dem Fenster ist ein diagramm, welches ein kurve zeichnen soll anhand der Datenvectoren. vector zeit + vector dataX = eine curve.

Über das event forder ich das fenster bzw. das diagramm auf eine kurve aus den akturellen Daten zu zeichnen. Aber während es noch zeichnt, und es länger dauern würde evtl. und der thread schon erneut einen datensatz anfügt , müsst es ja ein crash geben oder?

Wie würded ihr das am beseten syncroniesren? Das diagram macht sich keine copy der daten, es hat einen zeiger auf die aufzeichnungdaten mit jeweils 2 iteratoren start/ende Range auf den vector.

Wenn das diagramm den gesamten vector zeichnet und zur gleichen zeit fügt der thread ein element hinzu könnte es ja ein progarmm geben. da der vector ja evlt. durch das anfügen eines neuen elements erst umkopiert werden muss, und so das diagramm nich lesen kann.

Wäre es sinnvoller es mit einer liste zu machen? weil ich da ja theoretisch problemmos ein element anfügen kann ohne das die davorliegenden element /iteratoren zu beeinflussen?

Hallo Leute,

ich habe ein Datarecorder.. dieser läuft in einem eigenen Thread und fügt in einem best. Intervall datensätze an einen/mehrere std::vectoren. Bei jedem Iternvall schickt der Thread eine event "Neue Datensatz" an ein fenster.
In dem Fenster ist ein diagramm, welches ein kurve zeichnen soll anhand der Datenvectoren. vector zeit + vector dataX = eine curve.

Heisst "Event" in diesem Kontext eine Windows-Event? Welche Plattform benutzt Du? Welche Thread API benutzt Du?

BorisDieKlinge schrieb:

Über das event forder ich das fenster bzw. das diagramm auf eine kurve aus den akturellen Daten zu zeichnen. Aber während es noch zeichnt, und es länger dauern würde evtl. und der thread schon erneut einen datensatz anfügt , müsst es ja ein crash geben oder?

Wenn was länger dauern würde? Wenn das Zeichnen länger dauert als das Lesen?

BorisDieKlinge schrieb:

Wie würded ihr das am beseten syncroniesren? Das diagram macht sich keine copy der daten, es hat einen zeiger auf die aufzeichnungdaten mit jeweils 2 iteratoren start/ende Range auf den vector.

BorisDieKlinge schrieb:

Wenn das diagramm den gesamten vector zeichnet und zur gleichen zeit fügt der thread ein element hinzu könnte es ja ein progarmm geben. da der vector ja evlt. durch das anfügen eines neuen elements erst umkopiert werden muss, und so das diagramm nich lesen kann.

Wenn was passiert, kann es was geben? Ein Programm? Ein Problem? Muss der Vektor das Diagramm lesen?

BorisDieKlinge schrieb:

Wäre es sinnvoller es mit einer liste zu machen? weil ich da ja theoretisch problemmos ein element anfügen kann ohne das die davorliegenden element /iteratoren zu beeinflussen?

Sinnvoll wäre hier eine Queue. Die STL Queue ist aber nicht zwangsläufig Threadsafe ( die Wahrscheinlichkeit, dass sie es nicht ist, ist sogar ziemlich groß). Du solltest Dir also vielleicht eine eigene Klasse zur Entkopplung von Producer und Consumer bauen bzw. einen passenden STL-Container Threadsafe kapseln.

Ja es könnte je nach anzahl der Daten länger dauern das Diagramm zu zeichnen als einen datensatz hinzuzufügen:)

habe mir überlegt den Aufzeichnungs kontainer ungefähr so aufzubauen:

class DataRecording{
  Mutex mx;

std::list<dat> m_DATA;

 void addData(...){
    Lock(mx);

    m_DATA.push_back(....);
 }

 std::list<dat>::iterator GetLastRecord(){
    Lock(mx);
    return m_DATA.end();
 }
};

Thread Ruft dann die addDATA funktion auf, und meine Diagrmm ruft
GetLastRecord auf... das Diagramm darf ja jetzt die Daten bis zumletzen Record lesen ohne , und der thread derweil einen neuen anfügen...

Thread:

ThreadLoop(){

obj.addData();
PostMessage(WM_NEWDATA);
Sleep(1000);
}

Diagrammfenster:

OnNewData(..){

   GetLastRecord();
//Diagramm zeichnen
}

Dem Thread würde ich einen internen Puffer spendieren und TryLock() statt Lock() verwenden. Wenn nicht gesperrt werden kann, schreibst Du die Daten, bis zum nächsten Zyklus, einfach in den internen Puffer.

auserdem kann das Fenster ja asyncron zeichnen, weil es ja aus dem datenbereich liest, in dem der Thread nichts macht. .er fügt ja nur an, und verändert nichts...

naja während das Fenster zeichnet, und der Thread fügt einen neuen datensatz hinzu
muss ja nicht direkt wieder neu gezeichnet werden.. dann brauch ich da keinen puffer...

auserdem kann das Fenster ja asyncron zeichnen, weil es ja aus dem datenbereich liest, in dem der Thread nichts macht. .er fügt ja nur an, und verändert nichts...

Deshalb sagte ich ja: Queue.
Der Producer (Dein Rekorder) schiebt hinten was in die Queue rein. Der Consumer (Dein Fenster) entnimmt den vordersten Wert oder wartet, wenn nichts da ist.

das diagrm zeichnet alles daten von start der aufzeichnung bist zum gegenwärtigen zeitpunkt, oder man definiert die Zeit von der gegenwart bist - X! und diese rbereich kann ich ja mit iteratoren definierren. deswegen liste...

ne das geht nich, der recorder zeichnet ja kontinuierlich auf von start bis ende.. das heist das Datenvolumen steigt kontinuerlich dem aufzeichnusintervall..

das diagrm zeichnet alles daten von start der aufzeichnung bist zum gegenwärtigen zeitpunkt, oder man definiert die Zeit von der gegenwart bist - X! und diese rbereich kann ich ja mit iteratoren definierren. deswegen liste...

Und? Jeder aufgezeichnete Wert wandert in die Queue. Wenn das Zeichnen etwas länger dauert als das Einlesen, füllt sich die Queue halt langsam. Immer wenn der Zeichner mit dem Zeichnen eines Datums fertig ist, nimmt er sich das Nächste aus der Queue raus. Wo soll das Problem sein?
Wenn die aufgezeichneten Daten endlos lang sind, hättest Du ein Problem, wenn das Erzeugen schneller geht als das Verbrauchen. Aber das hättest Du dann so oder so.
PS: Wenn Du eh Win-API-Messages benutzt, könntest Du die Daten auch an die Message hängen. Die Messages werden nämlich vom OS für Dich gequeued.

Das Diagram soll abe keine eigenen container bzw. queue haben, sondern den primären list container des thread verwenden...

vll. reden wir aneinander vorbei^^

du meinst ne queue als puffer für das diagramm zwischen recording daten?

Das Diagram soll abe keine eigenen container bzw. queue haben, sondern den primären list container des thread verwenden...

vll. reden wir aneinander vorbei^^

Du hast doch nur einen Puffer. Der Producer schreibt rein, der Consumer liest raus. Wozu zwei?

Du beißt Dich viel zu sehr an die STL Strukturen fest. Für Dich bedeutet Queue=std::queue, oder? Ich meinte Queue als generalles Konzept zur Entkopplung bei Producer/Consumer Konstrukten:
Queue.
Mal davon abgesehen ist std::queue nur ein Adapter um einen Container der FIFO-Verhalten erzwingt. Als unterliegende Datenstruktur kannst Du auch eine std::list nehmen, wenn Dich das glüklich macht. Dafault ist std::deque.

Der Thread fügt die daten hinzu.... nicht die diagramm....

du meinst der thread liefert nen datensatz und mit der message OnNEWDATA soll das diagrmm den datensatz an die list anfügen?

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 weis was ne queue ist , aber ich weis nich was die mir nutzen soll^^

Was ist darann denn so schwer? Der Thread packt Daten in die Queue rein (er ist der Producer), Dein Zeichnen-Ding entnimmt Datan aus der Queue (das ist der Consumer).
Du magst vielleicht wissen, was eine Queue ist, aber Du hast anscheinend den Sinn davon noch nicht verstanden.

|-----------------------|                  |-----------------------|
|Thread                 |                  | Zeichnen Thread       |
|                       |                  |                       |
|                       |                  |                       |
|   Daten               |                  |        Daten          |
|     |                 |    Queue         |         /\            |
|     |      |---|---|---|---|---|---|---|---|---|    |            |
|     |--->  |   |   |   |   |   |   |   |   |   | ---|            |
|            |---|---|---|---|---|---|---|---|---|                 |
|                       |                  |                       |
|                       |                  |                       |
|                       |                  |                       |
|                       |                  |                       |
|                       |                  |                       |
|-----------------------|                  |-----------------------|

Was ist darann denn so schwer? Der Thread packt Daten in die Queue rein (er ist der Producer), Dein Zeichnen-Ding entnimmt Datan aus der Queue (das ist der Consumer).
Du magst vielleicht wissen, was eine Queue ist, aber Du hast anscheinend den Sinn davon noch nicht verstanden.

genau das will ich nicht.....

beim anlegen eine aufzeichnung wird eine recording objekt angelegt, jede sekunde für der thread daten hinzu.

Das Diagramm macht nichts anderes als Diese Daten noch anzuzeigen, muss aber nicht... das diagramm hat also nur eine referen aufdie list.. und zeig die daten an.. die eigentlich aufzeichnung macht ja der thread

aber danke für den denkansatz

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...

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..

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?

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.

Hast Du mal eine Referenz, wo das steht? Würde mich mal interessieren.

Ich hatte gehofft, ihr könntet mir eine entsprechende Referenz geben.

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?

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.).