Tag!
Bin wieder einmal dabei an einem alten D7 Projekt rumzufummeln.
Das Projekt ist multithreaded und verwendet CriticalSections zur synchronisation.
Für verschiedene Zwecke gibts da eine abgeleitete CriticalSection-Klasse die unter gewissen Umständen nicht blocken (und damit einen Deadlock erzeugen) soll sondern das Programm in einen kontrollierten Fehlerzustand bringen.
Diese Klasse (obwohl sehr einfach gestrickt) macht wohl Probleme. Habe sie daher für die Diagnose extrem vereinfacht und bin auf ein seltsames Verhalten draufgekommen.
Hier ist der Quellcode der Klasse (nicht wundern, daß das so aussieht als wäre es ziemlich sinnlos dafür eine eigene Ableitung zu machen - der ganze Kram, wegen dem es eine eigene Klasse wurde ist wegen der Fehlersuche entfernt)
Delphi-Quellcode:
unit uTestCriticalSection;
interface
uses SyncObjs;
type
TTestCriticalSection=class(TCriticalSection)
public
function TryEnter:Boolean;
end;
implementation
function TTestCriticalSection.TryEnter:Boolean;
begin
Enter;
Result:=True;
end;
end.
Im Programm gibts wird sie dann so eingesetzt:
Delphi-Quellcode:
var TestCS:=TTestCriticalSection;
//[...]
if not TestCS.TryEnter then begin
Log('Could not enter CS - Error');
//[ErrorHandling]
end;
Durch die extreme Verkürzung der Funktion TryEnter hätte ich erwartet, daß es entweder einen Deadlock geben muss (durch das Enter) oder die Funtion True zurückgeben muss. Die Zeile Log(...) und das Errorhandling dazu sollte eigentlich nie erreicht werden.
Trotzdem passiert das ab und zu.
Ich habe bereits geprüft, daß die TestCS.Klasse zum Zeitpunkt des Aufrufs auch korrekt initiert wurde. Es ist auch die Selbe TestCS für alle Teile des Programms die sie nutzen...
Warum gibt TryEnter also hier ab und zu False zurück? Steh ich hier nur auf der Leitung? Wirklich reproduzieren kann ich's leider nicht - nicht in der eigentlichen Applikation und schon gar nicht in dem Testprogramm das ich mir gebaut hab. Aber es tritt ab und zu auf - wie ich am Fehlerhandlich sehen kann
Jemand eine Idee?
Danke
Luggi