Delphi-PRAXiS
Seite 1 von 2  1 2      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Programmieren allgemein (https://www.delphipraxis.net/40-programmieren-allgemein/)
-   -   TInterlocked außerhalb eines TThreads? (https://www.delphipraxis.net/193187-tinterlocked-ausserhalb-eines-tthreads.html)

SneakyBagels 2. Jul 2017 08:42

TInterlocked außerhalb eines TThreads?
 
Ich säubere gerade meinen Code und ersetze an ein paar Stellen Inc() durch TInterlocked.Add().

Hat TInterlocked überall den Vorteil den der Befehl bringen sollte (Sicherheit beim Schreiben der Variable) oder muss das zwingend aus einem TThread aufgerufen werden?

Uwe Raabe 2. Jul 2017 09:08

AW: TInterlocked außerhalb eines TThreads?
 
Zitat:

Zitat von SneakyBagels (Beitrag 1375784)
Hat TInterlocked überall den Vorteil den der Befehl bringen sollte (Sicherheit beim Schreiben der Variable) oder muss das zwingend aus einem TThread aufgerufen werden?

Was verstehst du denn unter "Sicherheit beim Schreiben"? Solange die zu inkrementierende Variable nur aus einem Thread (z.B. dem Hauptthread) benutzt wird, besteht ja überhaupt keine Gefahr. Sobald aber auch andere Threads ins Spiel kommen muss das Interlocked immer verwendet werden (auch aus dem Hauptthread) - solange keine anderen Schutzmechanismen (z.B. CriticalSection) aktiv sind.

SneakyBagels 2. Jul 2017 10:15

AW: TInterlocked außerhalb eines TThreads?
 
Zitat:

Was verstehst du denn unter "Sicherheit beim Schreiben"? Solange die zu inkrementierende Variable nur aus einem Thread (z.B. dem Hauptthread) benutzt wird, besteht ja überhaupt keine Gefahr
Hat es denn irgendwelche Nachteile, wenn man trotzdem überall TInterLocked statt Inc verwendet?

Uwe Raabe 2. Jul 2017 10:54

AW: TInterlocked außerhalb eines TThreads?
 
Zitat:

Zitat von SneakyBagels (Beitrag 1375787)
Hat es denn irgendwelche Nachteile, wenn man trotzdem überall TInterLocked statt Inc verwendet?

Durch den Oberhead beim Aufruf von TInterlocked ist das potentiell weniger performant:

Delphi-Quellcode:
Unit191.pas.39: TInterlocked.Increment(I);
005FA2E4 8D45F8           lea eax,[ebp-$08]
005FA2E7 BA01000000       mov edx,$00000001
005FA2EC E8B725F1FF      call TInterlocked.Add
005FA2F1 8945F4           mov [ebp-$0c],eax

Unit191.pas.40: Inc(I);
005FA2F4 FF45F8           inc dword ptr [ebp-$08]

SneakyBagels 2. Jul 2017 11:05

AW: TInterlocked außerhalb eines TThreads?
 
Ich habe das gerade mal geprüft und eine etwas längere Prozedur gestartet die gewisse Dinge tut - und das 3550 Mal.
Wenn es einen Unterschied gibt, dann liegt der im Millisekundenbereich.
Mit Inc() war der Prozess in 45 Sekunden erledigt, mit TInterLocked.Add in 44.

Und selbst wenn es umgekehrt wäre, würde ich trotzdem TInterLocked aktuell bevorzugen. Ich hatte noch sehr viele Stellen mit Inc und das in einer multithreaded Anwendung.

dummzeuch 2. Jul 2017 11:56

AW: TInterlocked außerhalb eines TThreads?
 
Zitat:

Zitat von SneakyBagels (Beitrag 1375789)
Und selbst wenn es umgekehrt wäre, würde ich trotzdem TInterLocked aktuell bevorzugen. Ich hatte noch sehr viele Stellen mit Inc und das in einer multithreaded Anwendung.

Solange es sich um lokale Variablen handelt, ist Inc genauso "sicher" wie irgendein Interlocked-Befehl. Handelt es sich um globale oder sonstwie mehrfach benutzte Variablen (Felder), dann bedeutet die Verwendung von Interlocked-Befehlen nicht automatisch, dass die Verwendung threadsafe ist. Evtl. erzeugst Du damit lediglich ein falsches Gefühl der Sicherheit.

SneakyBagels 2. Jul 2017 12:01

AW: TInterlocked außerhalb eines TThreads?
 
Zitat:

dann bedeutet die Verwendung von Interlocked-Befehlen nicht automatisch, dass die Verwendung threadsafe ist. Evtl. erzeugst Du damit lediglich ein falsches Gefühl der Sicherheit.
Wofür soll TInterLocked denn sonst da sein?

Das würde ja das hier revidieren:
Zitat:

Sobald aber auch andere Threads ins Spiel kommen muss das Interlocked immer verwendet werden (auch aus dem Hauptthread) - solange keine anderen Schutzmechanismen (z.B. CriticalSection) aktiv sind.

Uwe Raabe 2. Jul 2017 13:30

AW: TInterlocked außerhalb eines TThreads?
 
Zitat:

Zitat von SneakyBagels (Beitrag 1375797)
Zitat:

dann bedeutet die Verwendung von Interlocked-Befehlen nicht automatisch, dass die Verwendung threadsafe ist. Evtl. erzeugst Du damit lediglich ein falsches Gefühl der Sicherheit.
Wofür soll TInterLocked denn sonst da sein?

Das würde ja das hier revidieren:
Zitat:

Sobald aber auch andere Threads ins Spiel kommen muss das Interlocked immer verwendet werden (auch aus dem Hauptthread) - solange keine anderen Schutzmechanismen (z.B. CriticalSection) aktiv sind.

Das ist halt eine notwendige Bedingung, aber keine hinreichende.

jaenicke 2. Jul 2017 13:46

AW: TInterlocked außerhalb eines TThreads?
 
Zitat:

Zitat von SneakyBagels (Beitrag 1375787)
Hat es denn irgendwelche Nachteile, wenn man trotzdem überall TInterLocked statt Inc verwendet?

Es ist abgesehen von der Performance auch der Codequalität nicht gerade zuträglich. Denn jeder Leser überlegt bei einem solchen Quelltext zuerst wie an solchen Stellen parallele Zugriffe erfolgen könnten.

Und umgekehrt denkt jemand vielleicht, dass der Code schon threadsicher ist, obwohl nur die eine Variable threadsicher verändert wird und der Rest nicht geschützt ist. Wenn ich so unseren Code durchschaue, sehe ich nicht viele Stellen, an denen solch ein Interlocked-Befehl ausreicht. Den verwenden wir zur Synchronisation mit anderen Threads, aber für sich genommen würde der nur an ein oder zwei Stellen etwas bringen.

Um eine saubere Trennung der Threads usw. kommst du mit so etwas nicht herum...

SneakyBagels 2. Jul 2017 13:52

AW: TInterlocked außerhalb eines TThreads?
 
Zitat:

Um eine saubere Trennung der Threads usw. kommst du mit so etwas nicht herum...
Keine Sorge. Ich verwende nicht nur TInterLocked.


Alle Zeitangaben in WEZ +1. Es ist jetzt 10:19 Uhr.
Seite 1 von 2  1 2      

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz