EnterCriticalsection erzeugt für einige Zeit hohe CPU Last

[JonnyGuitar]

Hallo zusammen,

ich habe eine für Outlook eine Exchange-Client-Erweiterung geschrieden die Termine synchronisiert.
Das einlesen der Termine passiert in einem Thread mit einer Criticalsection.

Nehmen wir jetzt an es sind initial 20000 Termine vom Server eingelesen und weggeschrieben worden.
Am Ende verlasse ich die CriticalSection mit LeaveCriticalSection.
Beim erneuten EnterCrticalSection geht die CPU Last auf 100% und verbleibt dort so zwischen
5-10 Minuten. Danach geht das wieder auf 0 runter und auch der Debugger springt eine
Zeile weiter.

Hat eienr ne Idee woran das liegen könnte?


Gruss Jonny

[taveuni]

Ohne Code?
Vermutlich benutzt Du die Selbe Critical Section an mehreren Orten und erzeugst einen Deadlock?

[messie]

Den CriticalSections habe ich nie getraut, weil ich solche Effekte auch mal hatte. Seitdem arbeite ich mit Mutexen, das ist bisher stressfrei, auch bei größeren Pausen und hohem Datendurchsatz. Mutexe sind systemweit bekannt, gehören aber Deinem Programm und Du legst Timeouts etc. selbst fest.

Grüße, Messie

[JonnyGuitar]

@taveuni: Korrekt, ich benutze die CriticalSection an mehreren Stellen. Warum kann es dort zu Deadlocks kommen und wie kann ich das umgehen?

@messie: Ich kenne Mutexe um sicherzustellen das zum Beispiel ein Programm nur einmal gestartet werden kann. Wie kann ich denn damit eine CriticalSection ersetzen?


Gruss Jonny

[messie]

Delphi-Quellcode:

var
  DataMutex : THandle; //Mutex für die Zugriffssteuerung auf den Datenpuffer
  initialization
  DataMutex := CreateMutex(nil,false,nil);
  
  //im Thread oder in der GUI dann z.B.:
      try
        if WaitForSingleObject(DataMutex,100) = WAIT_OBJECT_0 then
        begin
          //Datenübergabe
        end
        else
        begin
          WriteError('DataMutex','hier ist was schief gelaufen');
        end;
      finally
        ReleaseMutex(DataMutex);
      end;

Das benutzen dann alle Routinen, die auf den Speicher zugreifen wollen, hier sehr schnelle Vorgänge. Deshalb ist auch schon bei 100ms ein timeout. Bei Dir würde so ein Wert dann eher bei 10000 liegen. Aber Du kannst das explizit festlegen (auch mit INFINITE), und Du selbst fasst den geschützen Bereich an und lässt ihn wieder los. Zusätzlich kann man damit auch mehrere Ebenen verschachteln.

Grüße, Messie

[omata]

Zitat von taveuni:

Ohne Code?

Zitat von JonnyGuitar:

@taveuni: ...

[Win32.API]

Eine CriticalSection ist aber wesentlich performanter als ein Mutex. Sie macht intern auch (fast) nichts anderes als das Snippet von messie. Ergo: Der Fehler liegt in deinem Code, nicht in der CS.

-Win

[messie]

Zitat von Win32.API:

Eine CriticalSection ist aber wesentlich performanter als ein Mutex. Sie macht intern auch (fast) nichts anderes als das Snippet von messie. Ergo: Der Fehler liegt in deinem Code, nicht in der CS.

-Win

Wieso ist die CriticalSection performanter, wenn sie intern annährend dasselbe tut?

Vorteil für mich ist der timeout, mit dem ich meine Vorgänge steuern kann.

Grüße, Messie

[Win32.API]

Eine CriticalSection ist größtenteils im Usermode implementiert, daher sind weniger Context Switches nötig. Es gibt auch die Funktion TryEnterCriticalSection mit der sich "Timeouts" realisieren lassen.

Ich bin aber der Meinung, dass eine CriticalSection den lock bekommen sollte, wenn sie ihn braucht. Wenn der Lock nicht zwingend Nötig ist, ist ein Event/Mutex/Semaphore besser geeignet.