Synchronize inerhalb globaler Funktion durchführen

[schwa226]

Ich habe natürlich den Code oben nur kurz reingetippt

Eigentlich ist die Funktion RemoveData in einer Class.
Wird die Funktion RemoveData von einem Thread aufgerufen wird aus der TThreadList das Item entfernt.

Danach wollte ich mit einer Funktion der Class ein Stringgrid in der Hauptform Updaten.
Beim AutoSizeGrid (anpassen der GridSpaltenbreite) was beim Updaten ausgeführt wird gibt es aber dann Probleme.

Ich habe jetzt auch versucht meiner Class den TThread zu übergeben, aber dann bekomme ich die Meldung das Synchronize protected ist.

Also kann Synchronize nur im Thread selber aufgerufen werden.
Ich hatte mir gedacht, ich kann eine Funktion machen, wo Daten der TThreadList bearbeitet werden und auch gleich das StringGrid in der VCL ein Update erhält.

Nun glaube ich, dass ich halt im Thread die TThreadList bearbeiten muss und dann noch extra im Thread danach das Synchronize durchführen muss.

[Memnarch]

natürlich get Synchronize nur innerhalb eines Threads. Dieser funktion musst du dan die Funktion übergeben, die du synchronisieren möchtest(also z.B. die updatefunktion).

MFG
Memnarch

[schwa226]

Habe es nun so gemacht!

Ich gebe in eine Private Var meine Daten und rufe dann das Synchronize im Thread auf.
Dies Sync Procedure ruft mit dann die Globale funktion auf und schraubt am StringGrid herum.
Dann gibt es keine Probleme.

Wie sieht es nun aus, wenn ein Thread das Synchronize ausführt und darin das LockList durchführt und nun ein anderer Thread auch das Synchronize ausführen will.
Wartet da der zweite thread darauf, dass der erste die Sync Procedure wieder verlassen hat oder kann es hier einen Deadlock führen?

[Uwe Raabe]

Ohne den konkreten Code, kann ich immer noch nur raten...

Aber: Wenn innerhalb RemoveStringInMemo ein LockList aufgerufen wird, darfst du während du das Synchronize aufrufst keien Lock auf die Liste haben, sonst ahst du schon deinen DeadLock. Durch das Synchronize ist dein Thread blockiert und im HauptThread geht das Lock nicht durch.

Wenn immer nur ein Element aus der Liste entfernt wird, merk dir doch den Index und ruf Synchronize nach dem Unlock auf.

Eventuell kannst du auch statt Synchronize Queue aufrufen, aber das kann dann ganz andere Nebeneffekte haben. Es gibt eben keine generelle Regel.

[himitsu]

TThread bietet Synchronize in mehreren Varianten, einige als Klassen-Methode, welche man direkt über TThread.Synchronize(nil, MyProc); nutzen kann.

Entweder mit einer Prozedur (TThreadProcedure) und womöglich mit einer globalen Variable (neuerdings auch als anonyme Methode),
oder als Methode (TThreadMethod) irgendeiner Klasse, mit einem Feld in dieser Klasse.

[Sir Rufo]

Zitat von schwa226:

Wie sieht es nun aus, wenn ein Thread das Synchronize ausführt und darin das LockList durchführt und nun ein anderer Thread auch das Synchronize ausführen will.
Wartet da der zweite thread darauf, dass der erste die Sync Procedure wieder verlassen hat oder kann es hier einen Deadlock führen?

Deadlock gibt es nicht ... weil das Locken auch nichts bringt.

Eine CriticalSection darf unter der gleichen ThreadID sooft betreten werden wie man lustig ist.
Und wenn der Aufruf per Sync erfolgt, dann befindest du dich im Kontext von MainThreadID!

Somit bringt dir die CriticalSection da nix ausser verschwendete Bytes im Source und Code.

Wer es nicht glaubt das geht und wird auch immer brav aufgerufen

Delphi-Quellcode:

procedure RemoveData(Data : Pointer);
var
  List : TList;
  i : Integer;
begin
  // Da aus dem Thread mit Sync aufgerufen wird
  // ist diese Bedingung immer erfüllt
  // und kann daher auch entsorgt werden
  if MainThreadID = GetCurrentThreadID then
  begin

      for i := 0 to List.Count - 1 do
      begin
        if List[i] = Data then
        begin

          List.Delete( i );
          // Hier noch der Aufruf zur Aktualisierung des Memos
        end;
      end;

  end;
end;

Es ist auch immer hilfreich an gewissen Stellen mit OutputDebugString oder dem Schreiben einer Log-Datei oder mit einem Haltepunkt im Debugger die Statuswerte zu prüfen.
(z.B. GetCurrentThreadID und MainThreadID )

[himitsu]

Zitat:

Wie sieht es nun aus, wenn ein Thread das Synchronize ausführt und darin das LockList durchführt und nun ein anderer Thread auch das Synchronize ausführen will.

Abgesehn davon, daß eh nur eine der Synchronize-Prozeduren gleichzeitig ausgeführt wird.
Also wenn ein Thread ein LockList macht, dann sollte er das am Ende auch wieder freigeben und nachdem dieser Synchronizeaufruf fertig abgearbeitet wurde, erst dann wird das andere Synchornize ausgefphrt und die Liste wäre ja schonwieder frei.
Gut, und zusärtlich das schon erwähnte Verhalten der CS, welche praktisch nur für andere Threads sperrt ... Synchronize-Prozeduren laufen ja immer im Hauptthread (dem der VCL) ab.

[schwa226]

Zitat von himitsu:

Abgesehn davon, daß eh nur eine der Synchronize-Prozeduren gleichzeitig ausgeführt wird.
Also wenn ein Thread ein LockList macht, dann sollte er das am Ende auch wieder freigeben und nachdem dieser Synchronizeaufruf fertig abgearbeitet wurde, erst dann wird das andere Synchornize ausgefphrt und die Liste wäre ja schonwieder frei.
Gut, und zusärtlich das schon erwähnte Verhalten der CS, welche praktisch nur für andere Threads sperrt ... Synchronize-Prozeduren laufen ja immer im Hauptthread (dem der VCL) ab.

Ok, danke für die Info!
Also brauche ich eigentlich gar keine TThreadList sondern es reicht eine einfach TList.
Den entweder greift der Hauptthread auf die Liste zu oder der Thread über Synchronize.

[Sir Rufo]

Zitat von schwa226:

Zitat von himitsu:

Abgesehn davon, daß eh nur eine der Synchronize-Prozeduren gleichzeitig ausgeführt wird.
Also wenn ein Thread ein LockList macht, dann sollte er das am Ende auch wieder freigeben und nachdem dieser Synchronizeaufruf fertig abgearbeitet wurde, erst dann wird das andere Synchornize ausgefphrt und die Liste wäre ja schonwieder frei.
Gut, und zusärtlich das schon erwähnte Verhalten der CS, welche praktisch nur für andere Threads sperrt ... Synchronize-Prozeduren laufen ja immer im Hauptthread (dem der VCL) ab.

Ok, danke für die Info!
Also brauche ich eigentlich gar keine TThreadList sondern es reicht eine einfach TList.
Den entweder greift der Hauptthread auf die Liste zu oder der Thread über Synchronize.

Und damit auch wieder der Hauptthread