Was ist threadsicher?

[Olli]

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

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 von Olli:

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

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...

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)

[Mavarik]

Zitat von Sir Rufo:

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

Sack Reis... Hauptsache andere lesen es...

[Rollo62]

Naja, bei mir wars als neu markiert ??!!

[Stevie]

What is this thing you call "thread safe"?

[Mavarik]

Zitat von Stevie:

What is this thing you call "thread safe"?

Reichlich eng beleuchteter Sonderfall...

Richtig ist natürlich, dass wenn A Thread-Safe ist und B es benutzt, B noch lange nicht Thread-Safe seinen muss...

Bei der Thread-Safe-Frage geht es doch aber i.d.R. um zwei Dinge...

1. Wie muss ich meinen Thread-Code bauen, damit ich Ihn von mehreren Seiten oder in einem Thread benutzen kann.
2. Ist die XY Routine oder das XY Object aus der RTL Thread-Safe oder reentrant.

Mavarik