var-Parameter mit Thread nutzen

[Viktorii]

Okay, mit dem synchronisieren muss ich mich dann wohl nochmal eingehender befassen.
Allerdings hat sich bei meinem praktischem Versuch gerade leider noch ein Problem aufgetan. Das Zwischenspeichen (in tempData) muss ich ja nicht nur wegen der Synchronistation machen, sondern auch damit ich USBReadAsync eine Variable übergeben kann, welche diese dann als var-Parameter nutzen kann.
TDataFrame ist ein Array mit 2.000.000 Elementen vom Typ Byte. Das scheint für den Stack zu groß zu sein:

---------------------------
Benachrichtigung über Debugger-Exception
---------------------------
Im Projekt ... ist eine Exception der Klasse EStackOverflow mit der Meldung 'Stack-Überlauf' aufgetreten.
---------------------------
Anhalten Fortsetzen Hilfe
---------------------------

Das Array muss allerdings so groß (unter Umständen noch größer) sein. Komme ich um das kopieren der Daten irgendwie herum?
Wenn nein, muss ich schauen, wie ich den Stack-Überlauf umgehen kann....
Vielen Dank

[sirius]

Ich glaube du musst hier mal das ganze Konzept auf den Kopf stellen.

Was erwatest du denn in data? Und wie hats du TDataFrame derzeit deklariet?

[Viktorii]

Das Konzept ist scheinbar noch nicht optimal. Ich arbeite zum ersten mal mit Threads und bin versuche gerade herauszufinden welches das beste Konzept ist.

In Data erwarte ich eine bestimmte Anzahl von Byte. Die Anzahl kann variieren, von ein paar Byte, bis zu mehreren hundert kByte.

Die Deklaration von TdataFrame sieht so aus:

Delphi-Quellcode:

TDataFrame  = array[0..2000000] of Byte;

Das Konzept für einmal Kommunizieren sieht so aus: Es wird immer ein Kommando gesendet und anschließend eins empfangen.
Ein Kommando besteht immer aus zwei Teilen: Header und Daten. D.h.: Es muss ein Header gesendet werden, wenn dieser Empfangen wurde, müssen die Daten gesendet werden. Wenn diese gesendet wurden, muss ein Header empfangen werden. Wenn der Header empfangen wurde, müssen die Daten empfangen werde.
Für einmal Kommunizieren erstelle ich einen Thread. In diesem Thread erstelle ich einen Thread für 'Sende Kommando'. In diesem Sende ich den Header, warte und sende die Daten. Damit wird dieser Thread beendet. Der Übergeordnete Thread hat solange gewartet und startet jetzt einen weiteren Thread zum Empfangen. Dieser empfängt den Header, wartet und empfängt die Daten. Dann beendet auch dieser Thread. Damit endet auch der übergeordnete Thread.
Ist dieses Vorgehen bei dieser Problemstellung so richtig?

[sirius]

Nicht nur an den Threads ist etwas nicht optimal, auch das mit dem TDataFrame ist irgendwie komisch. Jetzt fehlt mir aber Wissen um diese USB-Schnittstelle um dir weiterzuhelfen.

[Muetze1]

Wenn du TDataFrame als lokale Variable deklarierst, dann belegst du 2 MB auf dem Stack. Rufe diese Funktion dann noch einmal auf und dein Stack ist voll. Wenn du soviel Speicher brauchst, dann alloziier ihn dynamisch (GetMem(), etc).

[Viktorii]

Zitat:

Zitat von Muetze1

Wenn du TDataFrame als lokale Variable deklarierst, dann belegst du 2 MB auf dem Stack. Rufe diese Funktion dann noch einmal auf und dein Stack ist voll. Wenn du soviel Speicher brauchst, dann alloziier ihn dynamisch (GetMem(), etc).

Ja, das war mir klar, dass das der Grund für den Stacküberlauf ist. Danke für den Hinweis mit GetMem(). Werde mir die Routine anschauen....

Zitat:

Zitat von sirius

Nicht nur an den Threads ist etwas nicht optimal, auch das mit dem TDataFrame ist irgendwie komisch. Jetzt fehlt mir aber Wissen um diese USB-Schnittstelle um dir weiterzuhelfen.

Okay, aber das es hierbei um eine USB Kommunikation geht ist ehr nebensächlich. Es muss halt zwei mal eine (Sende-)Fkt. aufgerufen werden (diese braucht komischerweiser ein Pointer anstatt eines var-parameters, also muss ich hier nichts kopieren) und dann muss zwei mal die (Empfangs-)Fkt. aufgerufen werden (diese benötigt einen var-Parameter, anstatt eines Pointers, deswegen sehe ich hier das Kopieren der Daten bis jetzt als einzige, aber unschöne Lösung).
Die jeweils nächste Fkt. darf aber erst ausgeführt, wenn die Vorherige abgearbeitet wurde. Ob eine Fkt. abgearbeitet ist, kann ich in der jeweiligen Callback Fkt. feststellen, welche aufgerufen wird sobald eine Fkt. beendet ist.
Da die Menge der Daten die versendet/empfangen werden unterschiedlich groß sind, muss TDataFrame ein gewisse Größe haben.
Wie das Konzept meiner Threads ist, habe ich ja schon geschrieben. Für jegliche Anregungen oder Verbesserungsvorschläge bin ich sehr dankbar. Wie gesagt, ist das erste Mal das ich mit Threads arbeite.
Vielen Dank

[sirius]

Und bekommst du irgendwie heraus, wie viele Daten kommen.
(statt mit getmem zu arbeiten reicht auch schon ein dynamisches Array; Edit: oder ein String... ich würde je nach Datenart sogar ein Memorystream vorschlagen)

[Viktorii]

Zitat:

Zitat von sirius

Und bekommst du irgendwie heraus, wie viele Daten kommen.
(statt mit getmem zu arbeiten reicht auch schon ein dynamisches Array; Edit: oder ein String... ich würde je nach Datenart sogar ein Memorystream vorschlagen)

Ja ich weiss jedesmal (mehr oder weniger unmittelbar) bevor das Array an die Funktion übergeben wird, wie groß es sein muss(also wieviel Daten kommen bzw. rausgehen).
Von Memorystreams habe ich auch noch keine Ahnung. Werde ich mir auch mal anschauen...
Meinst Du dass die Threads, so wie sie mache, nicht gut gewählt sind? Es wird halt jedesmal ein Thread erstellt und anschließend wieder zerstört....

[sirius]

Das mit den Threads ist prinzipiell ok. Da das USBZeugs aber ergeignisorintiert läuft hätte man vielleicht auch auf den Thread verzichten können und eine "normale" Klassen benutzen können. Schaden tut es nicht.

Wenn du die Größe kennst, dann nimm doch ein dynamisches Array (var Data:array of byte) und setze jedesmal vor dem Aufruf die Länge (setlength(x,Länge)).
Musst du Data vorbelegen? Ich vermute nicht. Dann würde ich die Sache mit PDataFrame etc, ganz fallen lassen, sondern allein mittels synchronize arbeiten.

Wie startest du den Thread?
Was sind das für Daten?

[Viktorii]

Muss mich erst nochmal für Deine Geduld bedanken. Hab echt schon einige wertvolle Erkenntnisse sammeln können.

Zitat:

Zitat von sirius

Das mit den Threads ist prinzipiell ok. Da das USBZeugs aber ergeignisorintiert läuft hätte man vielleicht auch auf den Thread verzichten können und eine "normale" Klassen benutzen können. Schaden tut es nicht.

Welchen Thread genau hätte ich mir sparen können? Ich versuche die Struktur mal darzustellen:

Delphi-Quellcode:

USBJobThread
       |
       |_______SendCommandThread
       |                   |
       |                   |________USBWriteAsync
       |                   |
       |                   |________USBWritesync
       |
       |_______ReceiveCommandThread
                           |
                           |________USBReadAsync
                           |
                           |________USBReadAsync  (Data)

Zitat:

Zitat von sirius

Wenn du die Größe kennst, dann nimm doch ein dynamisches Array (var Data:array of byte) und setze jedesmal vor dem Aufruf die Länge (setlength(x,Länge)).

Das klingt nach einer guten Vorgehensweise. Werde ich so machen. setlength kannte ich nicht.

Zitat:

Zitat von sirius

Musst du Data vorbelegen? Ich vermute nicht. Dann würde ich die Sache mit PDataFrame etc, ganz fallen lassen, sondern allein mittels synchronize arbeiten.

Okay. Das habe ich (logischerweise) auch noch nie gemacht. Verstehe den Ansatz auch nicht so ganz und finde kein einfaches Beispiel. Könntest Du evtl. anhand von dem Quellcode im Post #4 das kurz ganz grob skizzieren, damit ich einen Anfang habe? Steige mit dem synchronize trotz TFM nicht so ganz durch. Wäre echt nett :?

Zitat:

Zitat von sirius

Wie startest du den Thread?
Was sind das für Daten?

Einen Thread starte ich beispielsweise so:

Delphi-Quellcode:

    ReceiveCommandThread := TBulkReceiveCommandThread.Create( aPipeHandles[1][0],
                                                              pData,              //RxData,
                                                              @DSPMessage);
    ReceiveCommandThread.Suspended := FALSE;

    Ret := ReceiveCommandThread.WaitFor;

Die Daten sind halt Nutzdaten, welche auf die Applikation keinen Einfluss haben.