Guten Morgen...

auch durch viel Lesen bin ich nicht schlauer geworden... Bei Synchronize wird immer vom Hauptthread gesprochen. Ist damit grundsätzlich der Hauptthread gemeint oder der Thread aus dem der Nebenthread gestartet wurde ?
Beispiel:
Hauptthread startet Thread1, Thread1 startet Thread2

wird jetzt in Thread2 Synchronize aufgerufen läuft dann die procedure im Kontext von Thread1 oder vom Hauptthread ?
Trifft letzteres zu...wie synchronisiert man Thread1 und Thread2 ?

Danke für Infos ?

Guten Morgen,

Synchronize wird verwendet um zu verhindern, dass zwei Threads parallel auf eine Methode
zugreifen.

Was willst Du denn konkret bewirken.

Soll Thread1 auf Thread2 warten bis etwas bestimmtes abgearbeitet wurde?

Nachtrag: Zum Thema synchronisieren fällt mir noch Design Pattern (Model View Controller[MVC] ein.

Grüße
Klaus

Damit sollte der Hauptthread gemeint sein, und dieser muss wohl die VCL benutzen. Wenn ich einen Nachfahren von TThread in einem nicht-VCL-Programm benutze, der Synchronize() verwendet, bleibt der Thread an dieser Stelle hängen, deshalb synchronisiere ich an diesen Stellen mit anderen Mitteln.
Ich weiß nicht genau, wie Synchronize() intern funktioniert, kann es nur vermuten, und überlasse das, bei Interesse, anderen Menschen...

Etwas konkreter...

Ich beabsichtige:
1. einen Hauptthrad (GUI + diverses)
2. einen Workerthread (übernimmt die Aufgaben wie download, parsen etc.)
3. dieser Workerthread soll wiederum für den Download jeweils einen Thread starten.

die Frage zielte darauf ab, wie ich den Response Stream aus dem Downloadthread sauber an den Workerthread zurückliefere. Die Synchronisation Workerthread -> Hauptthread...soweit klar.

Danke

.. mal so in Blaue

Workerthread (Thread1)
DownloadThread (Thread2)

Thread1 besitzt eine Methode updateThreadList(ThreadId, Nachricht)
Thread2 bekommt eine eindeutige ID sowie die ThreadAdresse von Thread1 beim Erstellen mitgeteilt.

Will Thread2 nun an Thread1 etwas berichten ruft er Thread1.updateThreadList(seineThreadID,'was will ich mitteilen') auf.

Nachtrag: ResponseStream, den kannst Du doch im Workerthread erstellen und dem DownloadThread mitgeben.

Grüße
Klaus

hmmm sieht reichlich umständlich aus.

In der Zwischenzeit kam ich grad drauf. Vieleicht sind die seperaten Download Threads eh sinnlos, weil die Anfragen nur zu einem Gerät gehen und das Ding nur eine nach der anderen abarbeitet ... da sollte eigentlich der Workerthread reichen.

Konzept überdenken....

Danke

In diesem Zusammenhang kann ich dir meinen abstrakten ThreadPool vorschlagen, der auch die Implementierung eines spezialisierten HTTPThreadPool enthält.

Wenn du das Archiv bei SourceForge heruntergeladen hast, wirst du auch ein Beispiel-Projekt unter "Examples\HTTPPool" finden. Schau dir das einfach mal an.

Es gibt leider eine Einschränkung, der ThreadPool ist erst ab Delphi 2010 funktionsfähig, aber du hast ja XE...

Man kann das auch Windows überlassen: http://www.michael-puff.de/Programmi...tml#x34-520008

Zitat von Luckie:

Man kann das auch Windows überlassen: http://www.michael-puff.de/Programmi...tml#x34-520008

Ich hoffe das wird jetzt hier nicht off-topic.

Bei QueueUserWorkItem handelt es sich mehr oder weniger um "anonyme" Threads, soll (unter anderem) heißen, dass innerhalb des Threads erstellte Objekte nicht geshart werden.

Verwendet man innerhalb eines Threads eine TIdHTTP-Instanz so kann man von den einsparenden HTTP-Spezifikationen (z.B. Keep-Alive) profitieren, wenn es für mehrere Anfragen verwendet wird und an den selben Host gerichtet ist.

QueueUserWorkItem ist nicht plattformübergreifend (Delphi soll es demnächst ja werden), wenn man hingegen auf TThread aufbaut, ist man es.