LeaveCriticalSection: Warum das nachfolgenden sleep(0)?

[Nogge]

Hallo Community,
Ich habe mich jetzt endlich (hfftl komplett) durch das Thema 'Threads' gelesen. Allerdings habe ich da noch eine Verständnisfrage: Nachdem LeaveCriticalSection ausgeführt wurde, habe ich keinen sofortigen (Lese-)Zugriff auf z.B. eine Variable, die innerhalb einer CriticalSection verändert wurde. Erst wenn ich ein sleep(0) voranstelle, wird LeaveCriticalSection richtig verarbeitet.
Wieso verhält sich Windows so :?:

Gruß Nogge

[Delphi-Laie]

Das interessiert mich auch. Es scheint generell einen "stabilisierenden" Effekt zu haben.

In Luckies Script "Threads mit Delphi" ist auch ein solches sleep(0) hinter LeaveCriticalSection enthalten, leider steht dort nicht, warum.

Mit Delphi-4-Compilaten habe ich ohne dieses sleep(0) die meisten Probleme, aber nur auf Windows XP mit Zweikernprozessor. Delphi-2-Compilate sind ohne dieses sleep(0) stabiler, aber auch nicht ganz fehlerfrei. Mit diesem sleep(0) ist es mit den Delphi-2- und Delphi-4-Compilaten besser, aber auch nicht völlig stabil.

Überhaupt keine Probleme ohne dieses sleep(0) gibt es auf Einprozessorcomputern, mit Lazarus-Compilaten (!) auf besagtem 2-Kern-Windows-XP und mit allen Compilaten auf Windows 7 und 8.1.

Ob es unter Windows 2000 und NT auf 2- oder Mehrkernprozessoren problematisch ist, kann ich derzeit leider nicht prüfen.

Was auch gar nicht funktioniert, ist, zwei kritische Abschnitte ohne zwischengeschaltetes sleep(0) sequentiell auszuführen. Zwischen LeaveCriticalSection und nachfolgendem EnterCriticalSection sollte mindestens ein sleep(0) stehen.

Ergänzung: Aus demselben Quelltext XE2-Compilate (32 Bit) generiert, funktionieren diese auf dem Zweiprozessoren-XP fehlerfrei, und zwar sowohl mit als auch ohne hintenangestelltes sleep(0). Merkwürdig...

[Der schöne Günther]

Delphi 2, Windows NT. Ernsthaft?

Sleep macht nichts anderes als die WinApi-Routine "Sleep" aufzurufen.

In der Doku dazu steht:´

Zitat:

A value of zero causes the thread to relinquish the remainder of its time slice to any other thread that is ready to run. If there are no other threads ready to run, the function returns immediately, and the thread continues execution.

Windows XP: A value of zero causes the thread to relinquish the remainder of its time slice to any other thread of equal priority that is ready to run. If there are no other threads of equal priority ready to run, the function returns immediately, and the thread continues execution. This behavior changed starting with Windows Server 2003.

Also bis WinXP tut es entweder das, was

Delphi-Quellcode:

TThread.Yield()

macht, oder auch gar nichts. Je nachdem wie es lustig ist.

[BUG]

Zitat:

Zitat von Nogge (Beitrag 450946)

Nachdem LeaveCriticalSection ausgeführt wurde, habe ich keinen sofortigen (Lese-)Zugriff auf z.B. eine Variable, die innerhalb einer CriticalSection verändert wurde.

Das solltest du mal genauer beschreiben. Außerhalb der CS solltest du nicht auf Daten zugreifen, die mit der CS geschützt sind. Da ist irgendetwas faul.
Das Sleep hilft, könnte aus der Hüfte geschossen an Timing-Effekten oder an eventuellen Speicherbarrieren beim Suspendieren des Threads liegen.

Mich würde ein minimales Beispiel interessieren, wo es ohne Sleep schief geht.

[taveuni]

Zitat:

Zitat von Nogge (Beitrag 450946)

Nachdem LeaveCriticalSection ausgeführt wurde, habe ich keinen sofortigen (Lese-)Zugriff auf z.B. eine Variable, die innerhalb einer CriticalSection verändert wurde.

Macht ja auch überhaupt keinen Sinn. Wofür hast Du denn die CS? Und: Was heisst keinen Zugriff? Exception? Mach mal ein Beispiel.

[Zacherl]

Generell erzwingt Sleep einen Context Switch, weshalb ein

Delphi-Quellcode:

Sleep(0)

normalerweise äquivalent zu

Delphi-Quellcode:

TThread.Yield()

bzw. den darunterliegenden APIs SwitchToThread und NtYieldExecution ist.

Wenn ein Thread frequentiert eine Critical Section betritt und verlässt (wenige Instructions / CPU Ticks zwischen Leave und Enter), sollte man nach dem Verlassen yielden, um dem Scheduler des Betriebssystems die Möglichkeit zu geben direkt einen anderen Thread auszuführen. Macht man dies nicht, kann es zu Starvation kommen. Praktisch alle aktuellen Betriebssysteme vergeben allerdings pro Thread auch ein Timeout, nach dessen Auslaufen ein Context Switch erzwungen wird. Yielden kann je nach Anwendungszweck trotzdem zu Performancesteigerung führen und eventuell Bottlenecks / Starvation eindämmen.

[BUG]

Zitat:

Zitat von Zacherl (Beitrag 1299172)

Macht man dies nicht, kann es zu Starvation kommen.

Ich habe völlig übersehen, das CS nicht Starvation-frei sind. Dann macht das yield nach dem verlassen oder vor dem Betreten tatsächlich Sinn. Das schlimmste was ansonsten passieren könnte, wäre dass Windows immer dann einen Kontextwechsel macht, während der Thread in der CS ist :stupid:


Das erklärt aber noch nicht das oben angedeutete Problem.

[Delphi-Laie]

Das ließ mir keine Ruhe, und mithin forschte ich an diesem Phänomen weiter (Programmhänger tauchen gelegentlich in meinem Sortierkino beim parallelen (Multithreading-)Mergesort unter besagtem Windows XP auf einem Zweiprozessorcomputer auf: Es werden gewisse Synchronizes zwar aufgerufen, jedoch kommt der Code nicht in der synchronisierten Prozedur an, und zwar auch dann nicht, wenn dieser Aufruf als kritischer Abschnitt gekapselt ist.

Den Grund für dieses (Fehl-?)Verhalten konnte ich zwar nicht finden, aber den Fehler wenigstens eingrenzen: Er scheint nur bei Compilaten mit Delphi 2-4 aufzutreten, ab Delphi 5 konnte ich diesen Fehler nicht reproduzieren. Da sogar die Lazarus-Compilate wie gewünscht reagieren (Freepascal ist ja gegenüber Fehlern besonders empfindlich), war mein Verdacht ohnehin in diese Richtung vorhanden. Mit Compilaten der Delphis 5-7 und XE2 (Turbo-Delphi spare ich mir, dafür extra zu installieren) funktioniert es problemlos.

Und ab Delphi 5 muß eben auch kein "sleep(0)" den kritischen Abschnitten mehr nachgeschaltet oder zwischen solche kritische Abschnitte eingefügt werden, es funktioniert dennoch.

Dennoch fände ich es interessant, wenn Luckie sich mal dazu äußern würde, denn in seinem Beispiel in der umfangreichen Anleitung ist ja auch dieser Befehl nachgeschaltet. Oder er weiß auch nichts anderes als das schon genannte dazu zu sagen.

[Dejan Vu]

Schreib ihm eine PN.

[Luckie]

Boah. Ihr wollt Sachen wissen. Ich glaube, das habe ich noch mit einer ID geschrieben, wo man den Quellcode noch mir Kreide auf Schiefertafeln kratzen musste. Und unter einem Betriebssystem, welches mittlerweile wohl im Museum ist.

Wie schon richtig bemerkt sorgt Sleep(0) dafür, dass der Thread den Rest seiner von der CPU zur Verfügung gestellten Zeitscheibe nicht mehr nutzt. Statt nach 20 ms (?) (XP) verlässt er die Zeitscheibe schon nach 10 ms, je nach dem wo er ist, wenn das Sleep(0) kommt. Dann kommt der nächste Thread dran. Es wird also zu dem nächsten Thread "geswitch".

Und ich tue jetzt einfach mal so, als wüsste ich, was ich damals getan habe. Der Thread verlässt die CriticalSection. Er ist also fertig mit dem, was er machen soll. Ergo braucht er auch keine Rechenzeit mehr. Also eigentlich nur eine winzige, vernachlässigbare Optimierung. So würde ich mir das jetzt, nach den Äonen die es das Tutorial gibt, erklären.