Hallo zusammen,

ich verstehe das mit der Enter/LeaveCriticalSection irgendwie nicht: bei mir schein dienicht zu locken:
Ich habe mir ein kleines eigenes logging zusammengebastelt(ja ich weiss: sowas gibt es schon fertig....dazu bitte keine Ratschläge, weil ich verstehen möchte was ich falsch mache):

Der init code(wird einmalig aufgerufen)

markieren

Delphi-Quellcode:

procedure InitLog(path : string);
begin
  InitializeCriticalSection(FLock);
end;

und das deinitialisieren

markieren

Delphi-Quellcode:

procedure FinalizeLog;
begin
  DeleteCriticalSection(FLock);
end;

Das Logging, welches aus mehreren Threads(u.a. einige Timer) aufgerufen werden kann:

zusammenfalten · markieren

Delphi-Quellcode:

procedure WriteLnLog(output : string;level:Integer=1);
var f_size : Integer;
begin
  if True then
  begin
    EnterCriticalSection(FLock);
    OutputDebugString('in');
try
   if True then
   begin
    if (not fileexists(logpath)) then
      rewrite(logfile)
    else
      append(logfile);
    if output = '' then
     writeln(logfile,.........)
   else
     writeln(logfile,........);
    closefile(logfile);
   end;
finally
  OutputDebugString('out');
  LeaveCriticalSection(FLock);
end;
  end;
end;

Wie man sieht habe ich outputdebugstring drin, und damit sollte man abwechselnd in,out,in,out,in,out,...
erwarten. Leider bekomme ich manchmal:

Debug-Ausgabe: in Prozess xxx.exe (3332)
Debug-Ausgabe: in Prozess xxx.exe (3332)
Debug-Ausgabe: out Prozess xxx.exe (3332)
Erste Gelegenheit für Exception bei $7C812A7B. Exception-Klasse EInOutError mit Meldung 'E/A-Fehler 103'. Prozess xxx (3332)

Warum die exception kommt ist klar: da ist die datei einfach zu, aber was mich wundert ist warum ich überhaupt 2* in diese sektion komme.

Kann mir mal irgendjemand erklären was ich da falsch mache? (nebenbei:ist BDS2006)

Danke schon malfür eure Mühe!

CriticalSection funktionieren nur mit Threads nicht mit Timer. Häng mal die Timer ab, dann müsste es passen.

it True then was das?

Timer? Doch, geht. Eine CriticalSection blockt zuverlässig alles ab, was da rein will - unabhängig davon, wo es herkommt.

In meinen Augen ein lohnenswerterer Ansatz: Nimm doch ein Objekt vom Typ TCriticalSection. Dort ist alles artig gekapselt und Du musst nur .Enter / .TryEnter / .Leave aufrufen. Funktioniert in meinen Augen zuverlässig wie ein Panzer.

Bei Logs finde ich eine asynchrone Lösung sinnvoller. Das heißt ich nehme einen Thread, der nur die Logs schreibt und synchronisiere in irgendeiner Form mit diesem Thread um die Daten asynchron dort hineinzupacken.
Zum Beispiel mit TThread.Queue(LogThread, ...) oder indem Windows Messages geschickt werden oder...

Das hat den Vorteil, dass die sendenden Threads nicht blockiert werden.

Ob TCriticalSection oder direkt die API-Funktionen macht vom Ergebnis her keinen Unterschied, da TCriticalSection diese nur kapselt. Allerdings ist es natürlich sinnvoll TCriticalSection zu verwenden um für andere Betriebssysteme gerüstet zu sein.

Der Quelltext wie er jetzt ist sieht aber eigentlich korrekt aus.

Zitat von Daniel:

Eine CriticalSection blockt zuverlässig alles ab, was da rein will - unabhängig davon, wo es herkommt.

Das ist formell nicht ganz richtig. Eine CriticalSection kann immer nur von einem Thread durchlaufen werden, von diesem allerdings auch mehrmals - andernfalls könnte der Thread sich selbst dead-locken. Ein innerhalb der gezeigten CriticalSection rekursiv aufgerufenes WriteLnLog würde also problemlos funktionieren und genau das gezeigte Phänomen erzeugen.

Der gezeigte Code fällt allerdings offenbar nicht darunter, aber andererseits ist er auch nicht mal compilierbar.

Hallo,

dass der code nicht compilierbar ist ist richtig: ich habe ihn auch auf die wesentlichen Punkte runter gestrippt um zu zeigen wo mein Problem ist.

Aber wie bekomme ich das Ding denn nun wirklich so zu, dass der Code nicht parallel durchlaufen werden kann?

Zitat von noisy_master:

dass der code nicht compilierbar ist ist richtig: ich habe ihn auch auf die wesentlichen Punkte runter gestrippt um zu zeigen wo mein Problem ist.

Eventuell hast du genau den entscheidenden Fehler dabei korrigiert. Denn so sieht es so aus als ob der Fehler so nicht kommen kann.

Versuch doch mal den Code so zu kürzen, dass er im Wesentlichen noch funktioniert und schaue ob das Problem noch auftritt. Wenn ja, kannst du dann den Code 1:1 zeigen, der das Problem verursacht.
Bzw. wenn du möchtest, kannst du den auch so wie er ist posten.

Mit der CriticalSection stellst Du ja schon mal sicher, dass sich verschiedene Threads nicht gegenseitig in die Quere kommen. Zur Not nutzt Du mal ein boolsches Flag, um zu erkennen, wer da wie oft rein will. Das ist keine beständige Lösung, könnte Dir aber einen schnellen Erkenntnisgewinn bringen, wenn Du einen Breakpoint auf die Stelle setzt, an der er ein zweites Mal rein will und Dir dann den Callstack ansiehst.

Zitat von Daniel:

Timer? Doch, geht. Eine CriticalSection blockt zuverlässig alles ab, was da rein will - unabhängig davon, wo es herkommt.

Hab mal eine kleine Demo gebaut(D2010):

Es kommt 2x "enter", das Programm läuft natürlich in einer Endlosschleife.

Wo liegt mein Denkfehler?

zusammenfalten · markieren

Delphi-Quellcode:

var
  CritcalSection: TCriticalSection;

implementation

{$R *.dfm}

procedure TForm6.Button1Click(Sender: TObject);
begin
  Timer1.Enabled := True;
  CS;
end;

procedure TForm6.CS;
begin
  CritcalSection.Enter;
  try
    OutputDebugString('enter');

    while True do
    begin
      Application.ProcessMessages;
      sleep(100);
    end;

  finally
    CritcalSection.Leave;
    OutputDebugString('leave');
  end;
end;

procedure TForm6.Timer1Timer(Sender: TObject);
begin
  Timer1.Enabled := False;
  CS;
end;

initialization
  CritcalSection := TCriticalSection.Create;
finalization
  CritcalSection.Free;
end.

Mach es mit Threads und ohne Timer.