Thread.Queue, Zeitmessung, Thread hängt angeblich

[QuickAndDirty]

Zitat:

Zitat von AJ_Oldendorf (Beitrag 1548882)

Übrigens nochmal zu meinem Hauptproblem mit dem VCL Hänger.

Ich habe festgestellt, dass der Hänger nur passiert, wenn die Anwendung als 64bit compiliert wurde.
Unter 32bit passiert es nicht.

Kann es sein das LLVM Threads auf eine seltsameweise dealociert?

[AJ_Oldendorf]

Zitat:

Wenn dir der standard reicht.

Alle Objekte von Delphi haben einen monitor. Damit kannst du den zugriff auf dieses Objekt threadsicher machen.
Das heist DU blockiert alle zugriffe auf das Objekt bis auf einen und alle threads warten in einer warte schlange und stehen so lange bis sie drann sind.

TMonitor leistet das selbe wie TCriticalsection...nur das der Monitor halt schon teil des Objekts ist, während TCriticalsection von dir in alle möglichen kontexte gesetzt werden kann.

Meine Liste ist doch beim Enqueue und Dequeue bereits durch ein Lock geschützt. Da brauche ich TMonitor doch nicht mehr oder?

Wie würde dein Beispiel denn aussehen, wenn du es mit 2 verschiedenen Events ausstattest und das in meinen Thread implementierst, der ja bereits die MessageQueue pollt?

Zitat:

Kann es sein das LLVM Threads auf eine seltsameweise dealociert?

Gute Frage, wollte die Info nur erstmal weitergeben

[Stevie]

Zitat:

Zitat von QuickAndDirty (Beitrag 1548884)

Kann es sein das LLVM Threads auf eine seltsameweise dealociert?

Was hat LLVM mit ner 64bit VCL Anwendung zu tun?

Zitat:

Zitat von AJ_Oldendorf (Beitrag 1548882)

Übrigens nochmal zu meinem Hauptproblem mit dem VCL Hänger.

Ich habe festgestellt, dass der Hänger nur passiert, wenn die Anwendung als 64bit compiliert wurde.
Unter 32bit passiert es nicht.

Dann würde ich mal gucken, ob nicht irgendwo was nicht richtig 64bit kompatibel ist in deinem Code.

Zum Profiling:

- Anwendung mit mapfiles detailed bauen (am besten auch debug dcus Haken setzen)
- SamplingProfiler (pfff, die Seite sagt immer noch kompatibel bis XE4 32bit, Blödsinn, 64bit und neuste Versionen gehen - ich werd Eric nochmal darauf aufmerksam machen) nehmen, in den Sampling Options "Start sampling on command only" wählen und Samples Gathering Mode auf "Monte Carlo Samples" stellen. Im code vor der entsprechenden Stelle ein

Delphi-Quellcode:

OutputDebugString('SAMPLING ON')

, was dem Profiler mitteilt, dass es ab hier losgehen soll, danach ggf dasselbe mit OFF. Dann ein Blick ins Ergebnis, was da auftaucht. Gut möglich, dass das nicht zielführend ist. Dann kann man noch mit VTune schießen.

Oder man geht ganz pragmatisch über den Sysinternal Process Explorer her und schaut sich den Callstack zum Zeitpunkt des Freezes an - nicht selten der Fall, dass ich bei sowas direkt ein WaitForSingleObject oder ähnliche Kandidaten finde.

[AJ_Oldendorf]

Zitat:

Dann würde ich mal gucken, ob nicht irgendwo was nicht richtig 64bit kompatibel ist in deinem Code.

Zum Profiling:

- Anwendung mit mapfiles detailed bauen (am besten auch debug dcus Haken setzen)
- SamplingProfiler (pfff, die Seite sagt immer noch kompatibel bis XE4 32bit, Blödsinn, 64bit und neuste Versionen gehen - ich werd Eric nochmal darauf aufmerksam machen) nehmen, in den Sampling Options "Start sampling on command only" wählen und Samples Gathering Mode auf "Monte Carlo Samples" stellen. Im code vor der entsprechenden Stelle ein OutputDebugString('SAMPLING ON') , was dem Profiler mitteilt, dass es ab hier losgehen soll, danach ggf dasselbe mit OFF. Dann ein Blick ins Ergebnis, was da auftaucht. Gut möglich, dass das nicht zielführend ist. Dann kann man noch mit VTune schießen.

Danke, werde ich testen. Du meinst ich muss

Delphi-Quellcode:

OutputDebugString('SAMPLING ON')

aufrufen, zu dem Zeitpunkt vor dem Hänger und

Delphi-Quellcode:

OutputDebugString('SAMPLING OFF')

wenn der Hänger vorbei ist, richtig?

Zitat:

Oder man geht ganz pragmatisch über den Sysinternal Process Explorer her und schaut sich den Callstack zum Zeitpunkt des Freezes an - nicht selten der Fall, dass ich bei sowas direkt ein WaitForSingleObject oder ähnliche Kandidaten finde.

Da der Freeze ja nur "kurz" ist, habe ich da überhaupt eine Chance mit dem Process Explorer? Ich habe damit noch nicht viel gearbeitet, muss mal gucken wo man da den Callstack sieht und ob man da schnell hinkommt zum Zeitpunkt des Hängers

[Stevie]

Zitat:

Zitat von AJ_Oldendorf (Beitrag 1548887)

Danke, werde ich testen. Du meinst ich muss

Delphi-Quellcode:

OutputDebugString('SAMPLING ON')

aufrufen, zu dem Zeitpunkt vor dem Hänger und

Delphi-Quellcode:

OutputDebugString('SAMPLING OFF')

wenn der Hänger vorbei ist, richtig?

Richtig - ggf kannst du auf das off verzichten und einfach direkt auf den Stop Knopf im Profiler klicken wenn der Freeze vorbei is - es geht halt darum, dass man nur das recorded was innerhalb des problematischen Zeitraums passiert. SamplingProfiler listet hier im Gegensatz zu "großen" Profilern wie VTune oder Superluminal nicht die Samples in einer Timeline auf, in der man im Nachhinein schauen kann, was im Zeitraum X so los war.

Zitat:

Zitat von AJ_Oldendorf (Beitrag 1548887)

Da der Freeze ja nur "kurz" ist, habe ich da überhaupt eine Chance mit dem Process Explorer? Ich habe damit noch nicht viel gearbeitet, muss mal gucken wo man da den Callstack sieht und ob man da schnell hinkommt zum Zeitpunkt des Hängers.

Bei kurzen Freezes ist das eher witzlos, da hast du recht.

[QuickAndDirty]

Zitat:

Zitat von Stevie (Beitrag 1548886)

Was hat LLVM mit ner 64bit VCL Anwendung zu tun?

War es nicht so dass der Hersteller von Delphi den 64Bit compiler nicht nochmal geschrieben hat sondern für alle versionen die nicht Win32 sind konsequent LLVM als compiler ziel benutzt? Ich weiß nicht wie sehr LOW LEVEL LLVM wirlich ist oder ob vielleicht threads ein paar high level ansätze haben.

habe mal nachgesehen...
tatsächlich
sind nur diese LLVM basiert
DCCIOSARM
DCCIOSARM64
DCCAARM
DCCAARM64
DCCLINUX64
DCCOSX64
also ist Windows64 einfach nur ein sau langsamer compiler, ohne guten grund.
Das hat mich wohl in die irre geführt.

[AJ_Oldendorf]

@Stevie:
Moin, habe das mal untersucht und nachdem ich auf den Stop Button im Profiler geklickt hatte, kam nach ein paar Sekunden die Anzeige, dass das Programm keine Rückmeldung mehr hat. Im Taskmanager waren 0% CPU Auslastung unf 12MB Speicher belegt. Meine Anwendung lief währenddessen noch weiter. Diese habe ich dann manuell beendet und dann kam der Profiler auch wieder "zurück". 94% Local und Global Ratio mit 4828 Samples ist die win32u.dll mit dem Aufruf NtUserMsgWaitForMultipleObjectsEx.
Ich denke mal, dass heißt, dort steht er am längsten drinne oder?
Das ist eigentlich auch klar, da dieser Aufruf von meinen Threads überall so gemacht wird (mit der MessageQueue) und dann anschließend mit dem PeekMessage.
Im Profiler die ersten Funktionen, die direkt mit meinem Quelltext zu tun haben, sind bei einem Ratio von 0.04% und <4 Samples.

So richtig sagt mir das jetzt erstmal noch nichts

Edit: Ich habe zu dem Thema Thread, Queue und Events ein separaten Beitrag aufgemacht, da es in diesem Beitrag eigentlich um die Analyse des VCL Hängers gehen soll

[AJ_Oldendorf]

So, neue Erkenntnisse:

Aufgrund des Profilers von Stevie, bin ich darauf aufmerksam geworden, dass ich den Hänger 2x nicht nachstellen konnte.
Warum?
Weil die Exe aus dem Profiler gestartet wurde und nicht aus der IDE.

Nochmal den Test ohne Profiler gemacht und es ist tatsächlich so.

Starte ich die Anwendung aus der Delphi IDE, kann ich den Fehler jedes Mal reproduzieren.
Starte ich die Anwendung OHNE die Delphi IDE, ist es nicht mehr reproduzierbar.

Mehrmals mit beiden Konstellationen versucht und immer das gleiche Ergebnis.
Also hängt sich der Debugger da irgendwo rein und erzeugt den Hänger in irgendeiner Form...
Na toll, muss man erstmal drauf kommen

[TomyN]

Hast Du schon mal den Application Verifier probiert?

[jaenicke]

Zitat:

Zitat von AJ_Oldendorf (Beitrag 1548947)

Also hängt sich der Debugger da irgendwo rein und erzeugt den Hänger in irgendeiner Form...

Der Unterschied liegt insbesondere bei Multithreadanwendungen im Timing beim Threadscheduling. Das Zusammenspiel der Threads ändert sich dadurch.

Das kann auch umgekehrt auftreten, nämlich, dass es im Debugger nicht passiert.

Das heißt allerdings nicht, dass das Debuggen direkt mit dem Fehler zu tun hat. Es bedeutet nur, dass es diesen leichter oder schwerer nachstellbar macht.

Ein Punkt, der direkt die Delphi IDE betrifft:
Diese setzt mit timeBeginPeriod..timeEndPeriod systemweit die Timer-Auflösung herunter, ich glaube auf 1. Dadurch verhalten sich insbesondere Aufrufe von Sleep anders.