Was ist threadsicher?

[boserPascal]

Allgemein regelt man dies über Semaphore. Das heißt du zählst eine Zahl beim Schreibzugriff hoch und wenn du fertig bist wieder runter. Geschrieben darf nun nur werden wenn Die Zahl Null ist, dh keine Lesezugriffe stattfinden. Du mußt also nur sicherstellen können, dass es zu Zeitfenster zum Schreiben kommt.

Gruß Stefan!

[DGL-luke]

Critical Sections eignen sich meistens auch. Ein Semaphore ist insbesondere dann nützlich, wenn... ne. Ein Semaphore ist bei sowas eigentlich gar nicht nützlicher als eine Critical Section, es sei denn, man will eine Warteschlange einrichten.

Oder?

[messie]

Zitat:

Zitat von Olli

Ich kann von der Benutzung der Delphi TThread-Klasse und der Synchronize-Methode eigentlich nur abraten.

Dann sag mal in ein paar Worten, warum und was Du stattdessen bevorzugst oder empfiehlst.

@Codewalker Ich nehme zum Synchronisieren Mutexe, da kannst Du mal in der Hilfe nachschauen. Finde ich übersichtlicher als die anderen Methoden.

Grüße, Messie

[Phoenix]

Zitat:

Zitat von messie

@Codewalker Ich nehme zum Synchronisieren Mutexe, da kannst Du mal in der Hilfe nachschauen. Finde ich übersichtlicher als die anderen Methoden.

:shock: Zurück in die Ausbildung!
Das Verfahren nennt sich Mutex (Mutual Exclusion / Wechselseitiger Ausschluss) und wird entweder mit (ggf. binären) Semaphoren, dazu zählen auch die Monitore, oder mit Locks implementiert. Der Codeteil, der durch einen Mutext geschützt ist, ist die Critical Section.

Also bitte nicht durcheinander würfeln.

[Olli]

Zitat:

Zitat von Phoenix

Zitat:

Zitat von messie

Ist es also möglich, aus mehreren Threads gleichzeitig lesend auf denselben Speicherbereich zuzugreifen ohne das abzusichern?

Klar. Nur lesen ist bei sowas nie ein Problem. Problematisch wird es erst, wenn dort zeitgleich geschrieben wird.

Ich habe da mal eine kleine Einfügung vorgenommen :mrgreen: :zwinker:

Atomische Operationen sind eigentlich nur bei einer Interlocked-Operation gegeben, bei Nicht-SMP/Nicht-Multicore aber theoretisch auch bei einfachen Operationen bis zur Standard-Wortbreite der CPU.

Zitat:

Zitat von messie

Zitat:

Zitat von Olli

Ich kann von der Benutzung der Delphi TThread-Klasse und der Synchronize-Methode eigentlich nur abraten.

Dann sag mal in ein paar Worten, warum und was Du stattdessen bevorzugst oder empfiehlst.

Direkt über die Win32-API gehen, oder eine eigene Threadklasse. Durch die Tatsache, daß viele Delphianer immer mehr zu Benutzern (von fertigen Komponenten/Klassen) verkommen statt zu Programmierern zu reifen, ist es scheinbar irrelevant geworden, was in der Doku zum Thema Synchronize steht/stand. Denn die Nachteile sind hinreichend dokumentiert. Ich zitiere mal aus der BDS2006-Hilfe:

Zitat:

Synchronize (private) Executes a method call within the main thread.

Wenn alles in Synchronize nicht mehr in dem Thread ausgeführt wird der durch die TThread-Instanz repräsentiert wird, dürfte jedem hier einleuchten was die übermäßige Benutzung dieser (IMO völlig falsch benannten) Methode bringt, nämlich das gleiche wie die Nicht-Benutzung von Threads. Habe es viel zu oft in Beispielcode innerhalb der Delphi-Community gesehen wie diese Klasse komplett falsch benutzt wird, daher die o.g. Einstellung.

[wicht]

Klar, mitdenken muss man schon. Ständig im Thread Synchronize benutzen ist in der Tat unsinning, aber wenn man alle Paar Sekunden Informationen an den Hauptthread übergeben möchte, klappt das doch?
Wie machst du es denn, wenn du kein Synchronize benutzt?

[Olli]

Zitat:

Zitat von wicht

Wie machst du es denn, wenn du kein Synchronize benutzt?

Ganz einfach, ich überlege mir welche Daten ich übergeben muß. Meistens ist das keine Unmenge und man kommt schon mit einer Fensternachricht an den Hauptthread klar. Ansonsten implementiere ich Locking. Aber im Großen und Ganzen umgehe ich eit Jahren Synchronize indem ich kein Delphi mehr für meine Hauptaufgaben benutze :mrgreen:

Anderes Beispiel: nähmen wir an jemand solle ein Array erstellen und mit Werten füllen. Das Erstellen kann im Hauptthread erfolgen, aber da die Werte bspw. über das Netzwerk angefragt werden, dauert das länger, weshalb man sich entscheidet einen Thread für jeden zu füllenden Wert zu erstellen (kann ja auch nacheinander geschehen um die Auswirkung von Timeouts zu vermindern, es müssen also nicht genausoviele Threads wie Werte existieren). Der Thread bekommt dann die Adresse des zu füllenden Wertes mit und beschreibt die unter Verwendung eines Locks (bei "viel" Daten) oder einer Interlocked-Operation bei einem kleinen Datum.

[Rollo62]

Hallo Olli,

ich benutze Locks wenn ich Variablen Schreibend/Lesend austauschen möchte,
und Syncronize wenn ich mal eine Message an den Hauptthread absenden muss.

Ganz verteufeln würde ich Syncronize nicht, denn im Prinzip macht es doch
auch nur intern was man sonst von Hand schreiben müsste.
Ich gebe aber zu das ich mir die Implementierung von Synchronize noch nicht angesehen haben.

Und es gibt auch noch Queue, hälst du davon dann auch nichts ?

Einen Riesenvorteil gegenüber deiner Win.Thread.Create Lösung sehe ich in der Platformunabhängigkeit.
Das möchte ich wirklich nicht auf allen Platformen von Hand optimieren.

Rollo

[Mavarik]

Zitat:

Zitat von Olli (Beitrag 650518)

Meistens ist das keine Unmenge und man kommt schon mit einer Fensternachricht an den Hauptthread klar. Ansonsten implementiere ich Locking. Aber im Großen und Ganzen umgehe ich eit Jahren Synchronize indem ich kein Delphi mehr für meine Hauptaufgaben benutze :mrgreen:

Egal wie Du es nennst... Ob Synchronize oder ob Du es Windows überläßt... Weil was macht den Windows?
Eine Fensternachricht ist nahezu nix anderes als ein Commandpool der dann synchronisiert wird...

Naja und dann funktioniert es nur unter Windows... Das will doch keiner mehr...8-)

Synchrinize oder Queue sind die richtigen Wege um die GUI upzudaten... Kommt immer darauf an, ob ich dafür den Thread "anhalten" will oder nicht.

Ich gebe Dir Recht, dass in vielen Beispielen Threads mit GUI verbunden wird, aber das ist doch eher zur Demonstration - damit am sieht was ein Thread macht...

Der Trick an Threads eigentlich anders herum... Soviel wie möglich CPU-Zeit für den MainThread bereit zu stellen, damit der Bildschirm reaktiv bleibt...

[Sir Rufo]

Ob der Olli überhaupt noch antworten wird? (Beitrag von 2007 und der UserAccount ist gelöscht) :stupid: