Windows message queue - Limit erreicht?

[moelski]

Moin !

Wir haben einen USB Logger den wir auslesen. Dieser Logger sendet nach einem Kommando einen Block an Daten (~40.000 Telegramme á 57 Byte).
Also komponente verwenden wir NrComm (HID) - aber das spielt hier eh keine wichtige Rolle.

Die Daten werdenfolgendermassen empfangen:

Delphi-Quellcode:

procedure TForm1.HidAfterReceive(Com: TObject; Buffer: Pointer;
  Received: Cardinal);
var ByteData : AnsiString;
    i        : integer;
    _msg     : PHIDFeedback;
begin
  Inc(HidCount);

  for i := 0 to Received - 1
    do ByteData := ByteData + PAnsiChar(Buffer)[i];

  New(_msg);
  _msg.Data     := ByteData;
  _msg.HidCount := HidCount;
  PostMessage(self.Handle, WM_MY_HID_DATA, 0, Integer(_msg));    // Daten übergeben
end;

Und so ausgewertet:

Delphi-Quellcode:

procedure TForm1.DecodeHID(var Msg: TMessage);
var _msg                    : PHIDFeedback;
begin
  _msg := nil;
  try
    _msg := PHIDFeedback(Msg.LParam);

    // hier passiert noch mehr ...

    memo1.Lines.Add('[' + IntToStr(_Msg.HidCount) + '] ' + string(_msg.Hex));
  finally
    Dispose(_msg);               // Pointer löschen
  end;
end;

Wir nutzen also Windows Messages um die Daten aus dem Empfangsthread in den Mainthread zur Auswertung zu bekommen.

Diese Technik hat bis dato immer super funktioniert. Aber nun ergeben sich mit einem neuen Logger Probleme.
Wenn die Zahl der Telegramme zu gross wird (so ab > 30.000) dann gehen teilweise Telegramme verloren.

Gibt es bei den windows Messages irgendwelche Grenzen die man nicht überschreiten darf? Hat die queue nur eine bestimmte maximale Länge?

[jfheins]

Ich zitiere mal aus dem MSDN:

Zitat:

There is a limit of 10,000 posted messages per message queue. This limit should be sufficiently large. If your application exceeds the limit, it should be redesigned to avoid consuming so many system resources. To adjust this limit, modify the following registry key.

HKEY_LOCAL_MACHINE
SOFTWARE
Microsoft
Windows NT
CurrentVersion
Windows
USERPostMessageLimit

The minimum acceptable value is 4000.

http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx

Frage erledigt?

[moelski]

Ja Frage erledigt ... :cry:

[himitsu]

Ein Blick in PostMessage sagt alles:

Zitat:

There is a limit of 10,000 posted messages per message queue. This limit should be sufficiently large. If your application exceeds the limit, it should be redesigned to avoid consuming so many system resources. To adjust this limit, modify the following registry key.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\USERPostMessageLimit

Aber eh ich an windowsglobalen Einstellungen rumspiele, würde ich eher das Programmkonzept überdenken.

[edit]
da hat wer schneller geantwortet, als meine Leitung senden wollte :cry:


[add]
zu der For-Schleife sag ich mal Aua :shock:

Delphi-Quellcode:

procedure TForm1.HidAfterReceive(Com: TObject; Buffer: Pointer;
  Received: Cardinal);
var ByteData : AnsiString;
    i        : integer;
    _msg     : PHIDFeedback;
begin
  Inc(HidCount);
  New(_msg);
  SetLength(_msg.Data, Received);
  MoveMemory(@msg.Data[0], Buffer, Received);
  _msg.HidCount := HidCount;
  PostMessage(self.Handle, WM_MY_HID_DATA, 0, Integer(_msg));
end;

PS: Wenn du/ihr noch etwas Zeit habt:
http://www.delphipraxis.net/156006-n...omponente.html

[moelski]

Moin !

Zitat:

zu der For-Schleife sag ich mal Aua

Is ja gut ...
Aber das ist im Moment das kleinste Problem.

Hast du nicht einen Tip wie ich die Daten vom Empfangsthread Resourcen schonender zum Mainthread bekomme ?

[Luckie]

Der Speicher von _msg wird nicht wieder freigegeben.

Delphi-Quellcode:

 New(_msg);
  _msg.Data := ByteData;
  _msg.HidCount := HidCount;
  PostMessage(self.Handle, WM_MY_HID_DATA, 0, Integer(_msg)); // Daten übergeben

[moelski]

Moin !

Zitat:

Der Speicher von _msg wird nicht wieder freigegeben.

Sollte doch in DecodeHID mittels Dispose(_msg) erfolgen ?

[Luckie]

Lokale Variablen verlieren ihre Gültigkeit beim Verlassen der Routine. _msg aus HidAfterReceive ist in Decode-Dingsbums unbekannt. Zu mal du in Decode-Dingsbums _msg auch deklariert hast. Das sind zwei unterschiedliche Variablen, auch wenn sie gleich heißen.

[himitsu]

Du könntest ja auf eine andere/größere Queue/Liste ausweichen?

Delphi-Quellcode:

uses SyncObjs, Generics.Collections;

var
  QueueCS: TCriticalSection;
  Queue: TQueue<THIDFeedback>;


var
  Temp: THIDFeedback;
begin
  // hid-thread
  SetLength(Temp.Data, Received);
  MoveMemory(@Temp.Data[0], Buffer, Received);
  Temp.HidCount := HidCount;
  QueueCS.Enter;
  try
    Queue.Enqueue(Temp);
  finally
    QueueCS.Leave;
  end;


  // mainthread
  QueueCS.Enter;
  try
    Found := Queue.Count > 0;
    if Found then Temp := Queue.Dequeue;
  finally
    QueueCS.Leave;
  end;
  if Found then
  begin
    // temp auswerten
  end;

Statt Record, CS und gen. Queue könnte man auch TThreadList mit Objekten nutzen.

[Basilikum]

Zitat:

Zitat von Luckie (Beitrag 1067198)

Lokale Variablen verlieren ihre Gültigkeit beim Verlassen der Routine. _msg aus HidAfterReceive ist in Decode-Dingsbums unbekannt. Zu mal du in Decode-Dingsbums _msg auch deklariert hast. Das sind zwei unterschiedliche Variablen, auch wenn sie gleich heißen.

Oberflächlich betrachtet ist diese Aussage natürlich korrekt - aber wenn man es genauer anschauen würde, würde man erkennen, dass zwischen den beiden Funktionen die erwähnte Windows-Message-Queue steckt, welche den Pointer auf den vermeindlich nicht freigegebenen Speicher an die Funktion überliefert, welche den Speicher dann korrekt freigibt - das Speicher-Handling ist korrekt...

[moelski]

@himutsu:
Danke das werde ich doch glatt mal ausprobieren.

@Luckie:
Basilikum hats ja schon geschrieben. Ich übergebe ja einen Pointer mit PostMessage.
http://edn.embarcadero.com/article/22411
Da wird das übrigens auch so gemacht.

[Luckie]

OK, aber was passiert, wenn es dabei zu einem Fehler kommt? Dann hast du den Schlamassel.

[moelski]

Zitat:

Schlamassel

Den habe ich gerade schon ohne Fehler :)

Drum versuche ich mich gerade an himutsu Vorschlag.

[himitsu]

Da hab ich grad noch was gefunden :mrgreen:
http://www.delphipraxis.net/142681-generics-stack.html

[moelski]

Moin himitsu

Zitat:

Dank der Generics kann man ihn in allen möglichen Formaten erstellen
und er ist auch noch threadsicher.

:shock: :shock: :shock: WOW !!

Ich bin echt beeindruckt. Das könnte doch schon mein Problem lösen :) :thumb:

Eine Frage hät ich aber noch ...
Ich habe deinen Codeschnippsel von Post #9 mal in meine testanwendung eingepflanzt.
Das funktioniert soweit auch. :thumb:
Nun stellt sich mir nur noch die Frage ... Wie gebe ich dem Hauptthread nun zu verstehen das er sich mal um Daten kümmern soll?

- Timer ? Unschön und sicher nicht der beste Weg.
- Windows Message ? Nur wann wird die abgefeuert (Ich muss ja sicherstellen das ich nach dem Empfang auch immer die ganze Queue leer "lese").
- ??

[s.h.a.r.k]

Mal ganz blöde gefrage: Wie kann es sein, dass die Message Queue voll läuft? :grubel: Der Main-Thread müsste ja quasi komplett still stehen, dass dieser die Nachrichten, die er bekommt, nicht abarbeitet. Oder kann es sein, dass zu viele Nachrichten kommen, was aber dann ziemlich krass wäre imho. Was passieren denn mit den Daten im Thread? Kann man diese nicht evtl. auch dort verarbeiten? Klingt für mich irgendwie nach einem Problem im Konzept selbst.

Zum Thema Benachrichtigung: Nachdem das Thread-übergreifend ist, wären hier Nachrichten das passende Mittel. Von Timern (also Pollen) bin ich bei Gott nicht der Fan. Aber da gabs doch irgendeine Technik mit Signalen... Musst mal Luckies Thread mit Delphi anschauen.

[moelski]

Moin !

Zitat:

Klingt für mich irgendwie nach einem Problem im Konzept selbst.

Da gebe ich dir voll Recht.
Ist "historisch gewachsen" und nun gibs halt ein Problem ... :(

Parallel arbeiten wir eh an einer neuen Version die Solche Probleme behebt.

Aber irgendwie muss ich jetzt eben die alte Software noch "fixen".

[s.h.a.r.k]

Du brauchst quasi einen schnellen Fix ;) Hm, Generics.Collections.TQueue hat OnNotify als Event. Allerdings weiß ich nicht, wie das läuft, wenn du diese Queue mit mehreren Threads befüllst -- also in welchem (Thread-)Kontext denn der Code der hinter dem Event steht dann ausgeführt wird. Ich denke mal fast, dass es denn der füllende Thread ist.

[moelski]

Moin !

Zitat:

Du brauchst quasi einen schnellen Fix

Sir yes Sir :)

Zitat:

Generics.Collections.TQueue

Hmm, habe das gerade auf D2010 getestet ... Und auf 2007 (wo die alte Soft entwickelt ist) ... Da gibs noch keine Generics, oder?

[jfheins]

Du könntest einfach einen Speicherbereich anfordern, für ein Array mit - sagen wir mal 10000 - Elementen. Wenn das voll ist, wird der Pointer auf das Array verschickt, ein neues Array angelegt und der Mainthread kümmert sich um die Freigabe des alten Speichers. Wär das nicht was?

[s.h.a.r.k]

Damit teilt man ja lediglich die Anzahl der Messages durch 1000, was ja schon mal ein Anfang wäre. Allerdings ist es immer noch fraglich, ob das ausreichend ist. Kannst du nicht eine Software bauen, die mal nur die zu erzeugenden Messages zählen kann? Einfach die Messages nicht weg schicken, sondern nur zählen, dann kannst daraus vielleicht eine Kennzahl ermitteln, wie groß das Array denn werden soll. Verbunden damit ist aber auch das Speicherproblem -> Wie groß würde ein Array den werden?!

Und: bist du sicher, dass du den Mainthread nicht an entscheidener Stelle beschleunigen kannst, sodass er die ankommenden Messages vielleicht schneller abarbeiten könnte?!

[jfheins]

Zitat:

Zitat von s.h.a.r.k (Beitrag 1067252)

Damit teilt man ja lediglich die Anzahl der Messages durch 1000, was ja schon mal ein Anfang wäre. Allerdings ist es immer noch fraglich, ob das ausreichend ist.

Die messagequeue sollte zumindest nicht mehr überlaufen. Wenn das zeug natürlich langsamer verarbeitet wird, als es reinkommt wird der Speicher langsam aber sicher knapp da ja alles gepuffert wird. Aber wo will man da sparen ohne Daten zu verlieren?
Andererseits ...

Zitat:

Verbunden damit ist aber auch das Speicherproblem -> Wie groß würde ein Array den werden?!

sollte das nicht allzu schlimm werden:

Zitat:

Zitat von moelski (Beitrag 1067184)

(~40.000 Telegramme á 57 Byte)

[himitsu]

Zitat:

Zitat von s.h.a.r.k (Beitrag 1067232)

Hm, Generics.Collections.TQueue hat OnNotify als Event. Allerdings weiß ich nicht, wie das läuft, wenn du diese Queue mit mehreren Threads befüllst -- also in welchem (Thread-)Kontext denn der Code der hinter dem Event steht dann ausgeführt wird.

TQueue ist nicht thread-save, also sollte das Event im Kontext des Befüllers ablaufen, also in dem betreffenden Thread.
Drum war auch bei dem Vorschlag die CS verbaut.

Nja, du könntest schon über 'nen Timer arbeiten, dann jeweils in einem Timerereignis mehrere Einträge aus dem Queue rausholen.