Probleme mit Enter/LeaveCriticalSection

[noisy_master]

@Daniel,

die Idee an sich ist nicht schlecht... hatte ich auch schon. Hat aber nur 2 Nachteile:
- wenn du weisst woher er beim 2. Mal kam ist schön, aber damit weisst du noch nicht woher er beim 1.
Mal kam
- Das Mit dem Boolschen Flag funktioniert dann auch nur durch Zufall, weil der Zugriff darauf auch
nicht atomar ist

@Sebastian
Tendenziell glaube ich nicht daran, dass ich den Fehler mit dem Strippen beseitigt habe: die Beiden Trues kommen aus der Abfrage ob logging aktiv ist und welcher loglevel aktiv ist, und im writeln wird der String vorher noch verschlüsselt

[Uwe Raabe]

Wie schon erwähnt, ist es einem einzelnen Thread durchaus erlaubt, eine CriticalSection mehrfach zu betreten, was zu dem von dir geschilderten Effekt führen kann. Ein mögliches Szenario hatte ich bereits beschrieben. Ohne den vollständigen Originalcode, bei dem der Fehler auftritt, kann man aber nichts mehr dazu sagen.

BTW, warum ist logfile keine lokale Variable?

[himitsu]

Zitat:

Im Timer funktioniert nicht

Ums nochmal ordentlich zu erklären:
Wenn alles in TTimern ist, dann läuft alles im Hauptthread
und da eine CriticalSection mehrfache Zugriffe vom selben Thread erlaubt, wird auch alles durchgelassen.
Das ist, damit ein Thread sich nicht selber sperrt, wenn er mehrmals durch die selbe CS will/muss.

* Also entweder keine Timer/Messages verwenden und Zugriffe aus unterschiedlichen Threads
* oder eine andere Sperre verwenden, welche nicht threadaffine arbeitet.

System.SyncObjs.pas (TMonitor, TCriticalSection, TMultiReadSingleWriter und Co. arbeiten threadaffine)


PS: Man kann auch den Button deaktivieren, so lange das OnClick arbeitet. (ist nur bissl unschön, wenn der Button fukusierbar ist und der Bokus danach wo anders steht)

[Mavarik]

Wenn Du CS aufgerufen hast, kommst Du da nie wieder raus...

Da die CS den Main-Thread blockt du aber mit dem Button Klick im Main Thread bist,

kannst Du X-Mal den Button drucken und er wird immer wieder reinlaufen und noch eine CS auf den Stack packen.

[zagota]

Zitat von himitsu:

Zitat:

Im Timer funktioniert nicht

Ums nochmal ordentlich zu erklären:
Wenn alles in TTimern ist, dann läuft alles im Hauptthread
und da eine CriticalSection mehrfache Zugriffe vom selben Thread erlaubt, wird auch alles durchgelassen.
Das ist, damit ein Thread sich nicht selber sperrt, wenn er mehrmals durch die selbe CS will/muss.

* Also entweder keine Timer/Messages verwenden und Zugriffe aus unterschiedlichen Threads
* oder eine andere Sperre verwenden, welche nicht threadaffine arbeitet.

Das kann ich nur bestätigen.
Der Threadersteller hat ein Mix aus Threads und Timer(n) und versucht es mit einer CriticalSection zu syncronisieren und das ist keine gut Idee.

[noisy_master]

Hallo zusammen,

aber ich dachte immer ein onTimer macht einen eigenen Thread auf, oder habe ich da jetzt was falsch verstanden?

Und welche locks arbeiten NICHT "threadaffin"?

[Neutral General]

Timer laufen im Hauptthread und funktionieren über Windows-Messages (WM_TIMER) genau wie Button-Klicks o.ä.
D.h. zwei Timer können auch dementsprechend NIE gleichzeitig laufen, weswegen du keine Critical Section brauchst wenn du nur Timer benutzt.

Bei Threads brauchst du Critical Sections. Und beides zu mischen ist wie schon gesagt keine gute Idee.

[Uwe Raabe]

Zitat von Neutral General:

Und beides zu mischen ist wie schon gesagt keine gute Idee.

Ebensowenig wie die Verwendung von Application.ProcessMessages...

[Mavarik]

Zitat von noisy_master:

Hallo zusammen,

aber ich dachte immer ein onTimer macht einen eigenen Thread auf, oder habe ich da jetzt was falsch verstanden?

Und welche locks arbeiten NICHT "threadaffin"?

ähhh NEIN

TimerOnTimer Aufrufe sind immer im Mainthread

[Uwe Raabe]

Zitat von noisy_master:

Und welche locks arbeiten NICHT "threadaffin"?

Es gibt keine! Ein solcher Lock wäre entweder unnötig oder würde den Thread zum Stillstand bringen. Überleg doch mal - wie sollte das gehen?