Also Jeffrey Richter schreibt:

Zitat von Jeffrey Richter:

Es gibt keine Interlocked-Funktion, die einfach nur einen Wert liest (ohne ihn zu ändern). da eine solche Funktion nicht nötig ist. Wenn ein Thread nur versucht, den Inhalt einer Variablen zu lesen, deren Wert nur mithilfe von Interlocked-Funktionen geändert wird, handelt es sich immer um einen brauchbaren Wert. Zwar wissen Sie nicht, ob Sie den ursprünglichen oder den geänderten Wert lesen, aber Sie wissen zumindest, dass es einer von beiden ist. Das genügt für die meisten Anwendungen.

Zitat:

... Zwar wissen Sie nicht, ob Sie den ursprünglichen oder den geänderten Wert lesen, aber Sie wissen zumindest, dass es einer von beiden ist...

Also das interpretiere ich dann mal so, dass ein solches Read dann zwar auch vom Ändern eines anderen Threads unterbrochen werden kann, aber eben nicht so, dass der eigentliche Variable-Wert dabei quasi in der Mitte zersäbelt würde. Der danach gelesene Variablewert ist dann entweder derjenige vor dem Zugriff des schreibenden Threads oder der, der sich nach dem Schreibzugriff erst ergeben hat... ---> und das ist ja nunmal auch eigentlich immer der normale Umstand mit dem sich solche quasi 'WatchDog'-Threads sowieso abgeben müssen (also entweder mit einem alten oder einem neuen Variablen- bzw. Flag-Wert etc.). Im Zweifelsfall müsste so ein Thread hier dann eben nur noch einen Schleifenumlauf mehr machen, um diesen neuen Wert dann endlich auch noch registriert zu haben ...und reagiert dann. In allen nicht-zeitkritischen Abläufen wäre das natürlich immer ok.

Thx, dieses brauchbare Info passte gut rein

Ein Problem bekommt man nur, wenn man vergisst, dass die unterschiedlichen Prozessoren (ohne InterLocked) unterschiedliche Ansichten des Arbeitspeichers haben können (durch asynchrone Caches).

Beispiel aus dem PSDK...

zusammenfalten · markieren

Delphi-Quellcode:

var
  Value: Integer;
  ValueHasBeenComputed: LongBool = False;

procedure CacheComputedValue;
begin
  if not ValueHasBeenComputed then
  begin
    Value := ComputeValue();
    ValueHasBeenComputed := True;
  end;
end;

function FetchComputedValue(out Val: Integer): LongBool;
begin
  if ValueHasBeenComputed then
  begin
    Val := Value;
    Result := True;
  end
  else
    Result := False;
end;

Das Problem ist hier... ein Thread der gerade CacheComputedValue aufruft und ValueHasBeenComputed setzt und mit den anderen Prozessoren synchronisiert hat, muss nicht zwingend den neuen Wert von Value in die gemeinsame Speicheransicht übertragen haben (auch wenn die Befehle hintereinander stehen!). Ein zweiter Thread (auf einem anderen Prozessor) könnte also ValueHasBeenComputed = True 'sehen' aber noch nicht den neuen Wert von Value.

Erst durch die Interlocked/Wait/CriticalSection/Synchronisations-Funktionen werden die Caches der Prozessoren synchronisiert.

markieren

Delphi-Quellcode:

procedure CacheComputedValue;
begin
  if not ValueHasBeenComputed then
  begin
    Value := ComputeValue();
    InterlockedExchange(ValueHasBeenComputed, True);
  end;
end;

Ergo: Lesen ohne Probleme, Setzen mit Interlocked.

ps: welche Operationen 'atomar' sind und welche nicht, steht in den jeweiligen Prozessor-Beschreibungen... grobe Richtlinie: Integer-Operationen die nur eine Prozessoranweisung benötigen.

Zitat:

Ergo: Lesen ohne Probleme, Setzen mit Interlocked.

Danke fürs nochmalige Bestätigen, und zwar auch für diesbezüglich etwas komplexere bzw. empfindlichere Konstruktionen wie Multiprozessor-PCs (wenn ich das richtig verstanden habe).

ich arbeite auch im moment an einer multithreading-anwendung und muss aus mehreren threads variablen lesen bzw. schreiben... da hats bei mir auch oft genug exceptions gehagelt

dann habe ich von den CriticalSections zur absicherung von solchen lese/schreibvorgängen gelesen...

und unter delphi gibt es die klasse TMultiReadExclusiveWriteSynchronizer...

ein einfaches

T:=TMultiReadExclusiveWriteSynchronizer.Create;

erstellt das objekt und mit

T.BeginWrite;
bzw.
T.EndWrite;
kann ein schreibvorgang abgesichert werden... sprich solange nicht T.EndWrite; aufgerufen wurde, haben andere threads keinen lese-zugriff und warten bis endWrite aufgerufen wurde...

Voraussetzung ist, dass Lesevorgänge dann auch mit T.BeginRead; und T.EndRead; umgeben sind...

T.BeginWrite;
Variable1:=Wert;
T.EndWrite;

T.BeginRead;
Variable2:=Variable1;
T.EndRead;

Lesen funktioniert gleichteitig schreiben nur exclusiv...

Vielleicht Bringts dem einen oder anderen was...

Zitat von Meflin:

nein, weil der, der schreiben will, normalerweise keinen zugriff bekommt, weil ja ein thread am lesen ist

Nein. Das Lesen einer Integervariablen ist atomar, das eines Paares von zwei aufeinanderfolgenden Integern schon nicht mehr, das heißt Thread 1 liest integer 1, verliert dann die Kontrolle, Thread 2 schreibt ein neues Paar, Thread 1 liest Wert 2 und schon hat Thread 1 inkonsistente Werte, nicht technisch aber doch fachlich.

Grüße
Woki

aja.
1) was is los?
2) was hat das mit meiner aussage zu tun?

Zitat von Meflin:

aja.
1) was is los?
2) was hat das mit meiner aussage zu tun?

es hat etwas mit deinem nein auf meine letzte Aussage zu tun, weil das nein falsch ist.
Außerdem ist die Tatsache, daß ein Thread im Rahmen seiner Arbeit daten liest, überhaupt kein Grund für den scheduler ihm nicht die Kontrolle zu entziehen.


Grüsse
Woki

also ich hab auch schon bisschen erfahrung mit den threads.. besonderst krass is ja die thread verwaltung und synchronisation
bei internet anwendungen ( z.b. multithreaded server portchecker ). Da hab ich mir immer einen thread gebastelt der sich die "jobs" aus einer für ihn zugewiesenen klasseninstanz ( index einer liste ) rausholt, die abarbeitet und dann die results wieder in seine instanzen schreibt.. diese lese/schreibzugriffe hab ich natürlich auch mit EnterCriticalSection(section); und Leave umklammern müssen...

was mich auch viel nerven gekostet hat ist die tatsache das wenn ich in einem thread globale variablen deklariert hab ( sieht ja so aus als ob die eigentlich nur in dem thread aktiv sein sollten ) oder sogar public oben in die thread classe geschrieben hab.. das das alle threads zubgriff drauf haben.. naja hab ichs halt in die private section rein geschoben und dann hatte jeder thread seine eigenen variablen die kein anderer veränderte o_O

schon hart mit den dingern.. aber wenns mal rennt dann rennts krass