Zugriff auf Objekte von Thread aus - Synchronize erforderl.?

[s.h.a.r.k]

hallo,

ich habe da mal eine prinzipielle frage bzgl thread: ich habe gelesen, dass man auf vcl-objekt nur mit synchronize zugreifen sollte, da es sonst komische effekt geben kann. das ist mir soweit auch verständlich.

nun ist es so, dass ich mir eigene klassen geschrieben haben, auf die ich per threads zugreife. diese klassen sind meist von tobject abgeleitet. muss ich, in so fern ich dann auf die methoden anderer objekte von einem thread aus zugreife, auch synchronize verwenden, oder macht das nichts?

als beispiel gebe ich mal eine log-klasse an und einen thread, der ständig die uptime der anwendung loggt.

mit freundlichen grüßen
der hai

[jfheins]

Wenn du von mehreren Thread aus auf die Klasse zugreifst, dann solltest du die Zugriffe absichern. Also z.B. wenn der Hauptthread das Objekt erzeugt, und and den Thread weitergibt.

Wenn das Objekt ausschließlich von einem Thread verwendet wird, dann brauchst du das imho nicht absichern ;)

[SubData]

Absichern musst du auch nur, wenn du Daten schreibst / veränderst.
Solange du auf Objekte von fremden Threads nur lesend zugreifst, dürftest du keine Probleme bekommen.

[gsh]

Zitat:

Zitat von SubData

Absichern musst du auch nur, wenn du Daten schreibst / veränderst.
Solange du auf Objekte von fremden Threads nur lesend zugreifst, dürftest du keine Probleme bekommen.

so würde ich das nicht sagen den was ist wenn der andere thread was rein schreibt während du gerade ließt?

Es ist eigentlich ganze einfach

Synchronize:
VCL-Thread <- Thread (Thread will auf VCL Object zugreifen)

Critical Sections:
VCL-Thread -> Thread (VCL will auf Thread zugreifen)
Thread <-> Thread


Wenn du eine Klasse erzeugst dann läuft diese immer in der instanz in dem du sie erstellst oder etwas aufrufst.
Also wenn du die klasse von der VCL erstellen lässt und auf einen Thread zugreifen willst dann musst du auch critical Sections verwenden.

Wenn du die klasse aber in einem thread erzeugst und in dieser klasse nur auf diesen thread zugreifst dann brauchst du nicht nichts spezielles.

[alzaimar]

Zitat:

Zitat von SubData

Absichern musst du auch nur, wenn du Daten schreibst / veränderst.
Solange du auf Objekte von fremden Threads nur lesend zugreifst, dürftest du keine Probleme bekommen.

:wall: Stimmt das auch, wenn man auf eine Eigenschaft lesend zugreift, die einen Getter hat, der wiederum irgendetwas verändert?

Ergo: Aufpassen, Code anschauen. Oder auf Nummer sicher gehen.

Und denjenigen, der in einem Getter etwas verändert, teeren, federn und dann lynchen.

[s.h.a.r.k]

gut, soweit so gut. ich habe mich nun etwas in das thema eingelesen, nru verstehe ich glaub einiges noch nicht ganz so richtig... :wall:

annahme: ich habe den haupt-thread und einen anderen - dies ist ja auch zwei andere beliebige threads anwendbar. beim haupt-hread habe ich ein objekt, welches auf die datenbank zugreift (klasse tdatabase). im anderen thread habe ich eine referenz auf dieses objekt. wenn ich nun beim "normalen" thread eine sql-anweisung mache, dann sollte diese ja innerhalb von critical sections stehen, da es sonst zu problemen kommen kann, nur wie implementiere ich das?

könntet ihr mir im folgenden quellcode sagen, wo ich die critical section einfügen muss?!? ich kann das ja als lokale (als innerhalb der Methode machen) variable definieren, in der tdatabase-klasse oder in der tmainthread-klasse!? was ist die lösung? :wiejetzt:

Delphi-Quellcode:

TMainThread = class(TThread)
private
  FDatabase : TDatabase;
public
  procedure execSQL();
end;

procedure TMainThread.execSQL();
begin
  FDatabase.execSQL('SELECT...');
  row := FDatabase.getDataFromRow(0);
  { ... }
end;

TSecondThread = class(TThread)
private
  FDatabase : TDatabase;
public
  procedure execSQL();
end;

procedure TSecondThread.execSQL();
begin
  FDatabase.execSQL('SELECT...');
  row := FDatabase.getDataFromRow(0);
  { ... }
end;

[sirius]

Du implementierst dies in eine eigene Ableitung von TDatabase oder in eine eigene Klasse (bspw. von TDatamodul), welche allein die Datenbank beinhaltet. Und dort baust du deine CS ein.

Alternativ würde ich einen eigenen Thread mit der Datanbank arbeiten lassen. Zumal ich mir nicht sicher bin, was die Komponenten im Hintergrund machen.

[s.h.a.r.k]

es ist klar, dass ich nicht alles bis auf das detail hin erklären kann, geht ja nur um das prinzip dabei, da ich es ja auch auf andere fälle anwenden muss. aber dann glaube ich das ganze verstanden zu haben.

die variable für die kritische sektion muss ich dann als klassenvariable (private) deklarieren, oder? und nicht lokal in die methode!?

bzw: was würde das für auswirkungen haben, wenn ich diese variable in der methode definiere? würde das dann überhaupt berücksichtig werden? :gruebel:

[alzaimar]

Eine 'TCriticalSection' mit seinen Methoden 'Enter' und 'Leave' besagt, das der Code zwischen dem 'Enter' und 'Leave' nur von einem Thread ausgeführt werden kann. Wenn der andere Thread auch 'da rein' will, dann wartet dieser 2.Thread beim 'Enter', bis der 1.Thread das 'Leave' ausgeführt hat.

1 Raum mit 2 Türen (Enter und Leave).
"Enter" schließt hinter sich zu, sobald jemand durch diese Tür den Raum betritt.
Die Tür "Leave" schließt die Tür "Enter" wieder auf, sobald durch diese Tür der Raum verlassen wird.

[Gausi]

Dabei ist aber wichtig, dass alle Threads bei jedem Zugriff auf die so geschützten Daten mit der Critical-Section arbeiten.

Ich würde das im Türenmodell eher so beschreiben: Man hat einen Raum mit einer Tür. Betritt ein Thread diesen Raum als CriticalSection, dann hängt er ein Schild an die Tür "Bitte nicht stören". Wenn ein anderer Thread auch in diesen Raum will (bzw. auf die Objekte darin zugreifen will), dann sollte er das auch über Enter/Leave CriticalSection tun, denn nur dann ist er so höflich und beachtet auch das Schild an der Tür. Ist ein Thread fertig, dann verlässt er den Raum und entfernt den Zettel.

Einfache Zugriffe auf Objektproperties (z.B. Integer-Werte) kann man auch per InterlockExchange Thread-sicher durchführen - das sollte auch schneller sein als jedes Mal in eine CriticalSection einzutreten.