Hallo Leute,

ich habe folgende Situation mit einem TMultiReadExclusiveWrite-Synchronisierer (MREW):

zusammenfalten · markieren

Delphi-Quellcode:

procedure TMyClass.A;
begin
  MREW.BeginRead();
  try
   //...
  finally
    MREW.EndRead();
  end;
end;

procedure TMyClass.B;
begin
  MREW.BeginRead();
  try
   // ...
   // rufe irgendwann evtl. mal über ein paar Ecken TMyClass.A (oder sich selbst rekursiv) auf
   // ...
  finally
    MREW.EndRead();
  end;
end;

procedure TMyClass.C;
begin
  MREW.BeginWrite();
  try
   //...
  finally
    MREW.EndWrite();
  end;
end;

Ich habe jetzt 2 Threads, nennen wir sie T1 und T2. T1 ruft öfter mal TMyClass.B auf und T2 öfter mal TMyClass.C. Ich nehme an, dass folgendes passiert:
- T1 ruft B auf, ist aber noch nicht über die oben erwähnten paar Ecken bei A angekommen
- T2 ruft C auf.
- T1 kommt bei A (oder auf einer tieferen Rekursionsebene wieder bei B) an.

Nun befindet sich ja T1 in dem geschützten Read-Block von procedure B, was beduetet das T2 bei BeginWrite() in Methode C warten muss. Nun kommt T1 bei A (oder nochmal bei B) an und wartet bei BeginRead() in A bzw. B, weil vorher eine BeginWrite()-Anfrage eingereiht ist, die aber nicht weiter kommen kann, weil ja T1 den MREW noch lesend in Beschlag hat. Quasi also folgende Reihenfolge:

(T1) MREW.BeginRead();
(T2) MREW.BeginWrite();
(T1) MREW.BeginRead(); --> Deadlock

Ist das so gewollt? D.h. dass zwei Threads, die ansonsten nix miteinander zu tun haben müssen, sich an einem MREW aufhängen können? Das verwundert mich deswegen, weil die Standard-Erklärungen für einen Deadlock normalerweise eine inkonsistente Akquirierung von mindestens 2 Locks oder einen nicht-reentranten Synchronisierer erfordert.

Ich benutze den MREW statt einer CriticalSection, weil ich tendenziell wesentlich mehr lesende als schreibende Aufrufe habe.

Ich bitte einfach mal um ein paar Kommentare dazu: z.B. was ihr in solchen Situationen macht, ob man nicht doch besser eine CriticalSection benutzen sollte oder wie man einen MREW tatsächlich reentrant bekommt.

Viele Grüße

Eigentlich sollte ein Thread mit einem offenen BeginRead ohne Probleme ein zweites Mal durch das BeginRead laufen, auch wenn ein anderer Thread im BeginWrite wartet. Zumindest unter XE3 (gerade offen) lese ich das aus den Sourcen. Zu Turbo Delphi, wie in deinem Profil angegeben, kann ich leider nichts sagen.

Es ist auch nicht schwer - allenfalls etwas länglich - einen entsprechenden, einfachen Testfall herzustellen. Ich habe dazu nur im Moment keine Zeit.

Wenn ein BeginRead offen ist, dann kann der selbe Thread nochmal ein BeginRead aufrufen, genauso wie andere Threads das können.

Auch könnte ein Thread ein BeginWrite aufrufen, selbst wenn vorher ein BeginRead in diesem Thread startete.
Wobei es da auf die Implementation ankommt.
Ein BeginWrite wartet mindestens, bis alle BeginReads aus anderen Threads beendet wurden.

Aber wenn man z.B. in zwei Thread ein BeginRead ausführt und daraufhin direkt ein BeginWrite, dann könnte/wird man in einen Deadlock laufen, da beide Threads auf das Ende der
Sperren des anderen Threads warten.

Sorry, hatte nicht explizit erwähnt, dass ich hier mit FreePascal arbeite.

Laut Kommentaren aus dem Quelltext priorisiert der Synchronisierer hier BeginWrite(), d.h. alle Reader sollen noch ihr Ding zu Ende bringen und alle weiteren BeginRead()-Aufrufe werden hintenangestellt, auch die eines aktuellen Readers.

Das ist jedenfalls heimtückisch, wenn ein solcher Synchronisierer nicht immer reentrant ist.

Weitere Tests haben das bestätigt. Ich weiß nicht, wie das bei Delphi genau aussieht von der Implementierung des Synchronisierers.

(Edit)
@himitsu: das mit dem BeginWrite() direkt nach BeginRead() geht zumindest hier bei FreePascal auch nicht, das habe ich auch einmal explizit getestet. Das führt unweigerlich zu einem Deadlock. Kann natürlich sein, dass das bei Delphi anders ist.

Zitat von himitsu:

Aber wenn man z.B. in zwei Thread ein BeginRead ausführt und daraufhin direkt ein BeginWrite, dann könnte/wird man in einen Deadlock laufen, da beide Threads auf das Ende der
Sperren des anderen Threads warten.

Das sehe ich anders! Das BeginWrite entfernt zunächst den eigenen ReadLock, bevor es auf die Freigabe der anderen ReadLocks wartet. Das erlaubt dem Thread mit dem ersten BeginRead mit seinem BeginWrite durchzukommen. Dieses CodeSite-Log zeigt, daß es funktioniert:

Vielliecht wurde da mal was geändert?

Es ist zwar schon viele Jahre her, daber (vermutlich) ist damals mal ein Projekt, an soneiner Stelle, öfters mal hängen geblieben.
Jedenfalls nach einem Umbau und vorherrigem Freigeben des BeginRead, blieb es dann nicht mehr hängen.

Stellt der nach dem EndWrite das BeginRead eigentlich wieder her?

Zitat von himitsu:

Vielliecht wurde da mal was geändert?

Der Test war jetzt mit XE3.

Zitat von himitsu:

Stellt der nach dem EndWrite das BeginWrite eigentlich wieder her?

Das BeginRead, ja!

Anscheinend gibt's da dann deutliche Unterschiede zwischen Free Pascal und den neueren Delphi-Versionen. Ich muss dringend mal schauen, wie Turbo Delphi das macht. Nicht, dass es da generelle, hinterlistige Inkompatibilitäten gibt.

Ich habe mir in der Zwischenzeit mal so weitergeholfen, dass ich eine Subklasse zu TMREW gebaut habe, die (durch eine eigene CriticalSection geschützt) über die Reader Buch führt und für jeden zählt, wie oft er reinkommt. Nur beim ersten Reinkommen und dem dazugehörigen Rauskommen eines Threads werden die entsprechenden BeginRead()- bzw. EndRead()-Aufrufe aus der TMREW-Klasse aufgerufen, anderenfalls die Zähler entsprechend erhöht bzw. verkleinert.

Da ich nur ein paar wenige Threads habe, die darauf zugreifen, geht das bis jetzt ganz gut.