Liste Thread sicher abholen

[oki]

gleicher Effekt!

oki

[oki]

so klappts

Delphi-Quellcode:

procedure TShutDownThread.GetWindowList(const AList: TWindowList);
var
  WinParamObj: TWinParamClass;
begin
  if not Assigned(AList) then
    Exit;
//  Lock;
  try
    AList.AssignList(FWindowList);
  finally
//    UnLock;
  end;
end;

Nach meinem vorherigen Verständnis ist das dann aber wohl eben nicht mehr Thread-sicher. Das ich keine Fehlermeldung bekomme, darauf geb ich nichts. Könnte auch nur Glück sein.

oki

[sirius]

Dann schau dir mal FLock.LockCount an und vergleiche vielleicht noch FLock.OwningThread.


Als Alternative gibts ja noch tryEnterCriticalSection. Aber das löst das eigentliche Problem nicht.


[roter KAsten]
Sieht nach Glück aus.

[oki]

Tja, ich hab das Abholen der Liste in meinem Demo mal auf einen Timer gelegt, der alle 500ms ein ListView aktualisiert. Benimmt sich anständig. Ich trau dem aber immer noch nicht über den Weg. Viel schlimmer ist, dass mein Verständnis über CriticalSection über den Haufen ist wenn das so ok ist.

oki

roter Kasten :lol: ich lese mich mal durch LockCount und und OwningThread durch. So lass ich das auf keinen Fall stehen.

[sirius]

Prinzipiell kann ich keinen fehler entdecken. Aber vielleicht geht irgendein Thread aus der Critical Section nicht mehr heraus. Das dürftest du an den Feldern von FLock sehen können (aber nicht selbst verändern!).

[oki]

Tja, tut mir leid, aber da komme ich nicht weiter. Die Hilfe spuckt nichts aus und die Deklaration in Windows bringt mich nicht sehr weit.

Delphi-Quellcode:

  _RTL_CRITICAL_SECTION = record
    DebugInfo: PRTLCriticalSectionDebug;
    LockCount: Longint;
    RecursionCount: Longint;
    OwningThread: THandle;
    LockSemaphore: THandle;
    Reserved: DWORD;
  end;
  {$EXTERNALSYM _RTL_CRITICAL_SECTION}
  TRTLCriticalSection = _RTL_CRITICAL_SECTION;
  RTL_CRITICAL_SECTION = _RTL_CRITICAL_SECTION;
  {$EXTERNALSYM RTL_CRITICAL_SECTION}

ich hab mich mal durch meine Getter-Methode sowie durch mein Execute debuggt. Der LockCount liegt konstant bei 0.

Im Anhang mal der Shot meines überwachten Ausdrucks FLock. Witzigerweise kommt mir da ein Versacht. Der ist wie folgt:

Kann es sein, dass der Aufruf nur für Zugriffe außerhalb der Klasse gültig ist. :gruebel: Nee, ich glaub das ist Quatsch.

oki

[oki]

Jo man, roter Kasten ist heut mein Ding.

Weitere Zugriffe sollte es eigentlich nicht geben. Ich habe meinen Thread als Klasse in einer Unit (logisch). Meine Testanwendung besteht aus dem Formular, ListBox, Timer. Der Timer holt periodisch eine aktualisierte Liste und überträgt die Werte in das ListView. Da ist nicht viel dran, ist ja auch nur zum testen der Klasse.

Mein Thread macht nicht anderes als in Execute meine WindowList anzuweisen sich zu aktualisieren. Das macht sie mit EnumWindows. Sollte auch nicht der Hit sein.

Gruß oki

[sirius]

Da mit die CS frei ist muss Lockcount -1 sein und OwningThread 0.
Jetzt schau noch mal den Record an bevor er im MainThread in das blockierende Lock geht. Und vergleiche owningthread mit MainThreadID (globale Variable in Unit System) und mit TThread.ThreadID.

[oki]

Hi Sirius,

klar mach ich. Vorher noch 'ne Theorie. Ich war grad an der frischen Luft und hab nachgedacht. Folgendes.

Lock sorgt doch dafür, dass die zugreifenden Threads angehalten werden, damit es nicht zu kollisionen kommt (landläufig ausgedrückt). Somit sperre ich doch meinen Thread selbst, wenn ich Lock im Execute aufgerufen habe. In meiner GetterMethode sehe ich , dass LockCount = 0 ist. Das kann doch dann nur mein eigener Thread sein der in Execute Lock aufgerufen hat. Wenn ich jetzt über die Gettermethode des gleichen Threads Lock aufrufe sperre ich mich doch sozusagen selbst. Meine Idee ist jetzt folgende. Wenn ich in meinem Execute nur FLock.LockCount auf -1 prüfe und die Liste nur dann aktualisiere wenn dieser Wert tatsächlich -1 ist, dann hab ich doch die Kontrolle. Die Frage ist dann doch nur, ob ich Lock in der GetterMethode des Threads aufrufen darf oder das meinem MainThread (Anwendung) überlassen muß.

Ich teste das erst mal. Sorry.


teste teste teste ...

Ist doch Blödsin, wenn ich auf -1 getestet habe greif ich doch wieder nicht Threadsicher auf die Liste zu. Ein Lock von aussen nutzt dann auch nichts. Ich muss mich wohl erst mal von meinem Ansatz lösen. Da läuft doch was in meinem Gehirn krumm. Das einzige, was ich sicher glaube ist, dass ich mich selber sperre. Das scheint sicher.

Gruß oki

[oki]

Mal ganz blöd gefragt, brauch einen Thread im Thread? oder bin ich grundsätzlich auf dem Holzweg. Ich debug jetzt erst mal um Sirius ein paar Antworten zu geben. Ist im Moment leichter als denken.

Gruß