Zitat von
WS1976:
ich finde deinen Code Klasse!
Danke
Zitat von
WS1976:
Ob das Ganze nötig ist oder nicht muss man sicherlich im Einzelfall überprüfen.
Wir haben hier ein Messaging-System, wobei die Clients per UDP Änderungen an einem Datenbestand mitgeteilt bekommen. Das Problem ist, das die Daten sowohl in eine interne Struktur eingepflegt, als auch visualisiert werden müssen. Teilweise rattern 100te von Paketen pro Sekunde ein. Damit die Anwendung nicht einfriert, schiebt der Empfangs-Event des UDP-Clients die vorzunehmenden Änderungen in die Jobliste. Die Visualisierung geschieht im OnIdle der Anwendung. Weiterhin müssen die Pakete jedoch an andere Programmteile weitergeleitet werden: auch dafür haben wir einen Job definiert. So ist gewährleistet, das es zu keiner Zeit zu irgendwelchen Verzögerungen kommt, auch wenn es kurzzeitig zu UDP-Bursts kommt.
Wir hatten vorher den Workerthread im Rahmen einer garbage collection im Einsatz, wo Zigtausende von Objekten freigegeben werden mussten. Das dauert doch ein paar Sekunden. Also haben wir Jobs definiert, die jeweils einige hundert Objekte freigeben. Damit läuft die Anwendung wieder flüssig.
Zitat von
WS1976:
Schon alleine um dahinterzukommen wie Threads funktionieren hat sich die Arbeit gelohnt.
Du hast mich durchschaut. Das war die Motivation für mich, diesen Code hier zu posten, weil viele hier Probleme mit Threads haben. Insbesondere die Verwendung der Semaphore als wirkungsvollere Alternative zum 'Resume/Suspend'-Mechanismus sowie das externe Antriggern des Threads ist es Wert, mal analysiert zu werden.
Weiterhin habe ich nur unglaublich komplexe Units zum Thema 'Worker threads' gefunden. Da dachte ich mir eben: Nö. Muss einfacher gehen.
Zitat von
WS1976:
( aber schnapp jetzt bitte nicht über )
Geht nicht. Zu alt.
@Luckie: Oder so.
Da lernt man aber nix über Threads.