Win32 Threads Designfrage

Reply to Win32 Threads Designfrage on Sat, 22 Apr 2006 17:58:40 GMT

std**Robin — Sat, 22 Apr 2006 17:58:40 GMT

Was ist performanter für eine Serverapplikation mit regem Netzverker und >10 Clients?

für jeden verbundenen Client einen eigenen Thread eröffnen und in diesem alles passieren lassen...
in der Main mit Select warten und bei Bedarf einen Thread erzeugen, der nur die eine Aktion abarbeitet....

Worauf ich hinaus möchte ist einfach die Frage ob der Aufwand für das ständige Thread erzeugen und beenden hoch bzw. "teuer" ist.
Und wie "teuer" im Vergleich das halten mehrer Threads ist...

Gruss
R

Reply to Win32 Threads Designfrage on Sat, 22 Apr 2006 18:05:11 GMT

Martin Richter — Sat, 22 Apr 2006 18:05:11 GMT

Di kannst mit einem Thread Pool arbeiten. Die Threads sind immer am laufen und warten auf Arbeit. Diese teilst Du Ihnen zu und wenn sie ihren Job getan haben kehren sie in den Wartezustand zurück.

Evtl. findest Du hier eine Anregung dazu:
http://www.codeproject.com/internet/jbsocketserver2.asp
http://www.codeproject.com/threads/SimpleThreadPoolManager.asp
http://www.codeproject.com/threads/Joshthreadpool.asp
http://www.codeproject.com/threads/thread_pooling.asp

Reply to Win32 Threads Designfrage on Sat, 22 Apr 2006 18:14:49 GMT

Ominion — Sat, 22 Apr 2006 18:14:49 GMT

Also wenn du immer bei jeder Einfrage einen neuen Thread erstellst und danach wieder schließt, ist das ziemlich Kostenaufwendig. Stell dir mal vor 50 User stellen alle 1 1/2 Sekunden ein Request an den Server. Danach machen sie eine halbe Sekunde nichts, und dann geht das wieder los. Der Server wird beim Request einen Thread erstellen, und ihn nach einer halben Sekunde wieder schließen. Erstmal noch nicht so zeitaufwendig (wahrscheinlich 5ms Verzögerung). Dann kommen plötzlich 100 User, und das Spiel beginnt vom neuen: 15ms Verzögerung. Dann kommen 500 und dann vielleicht sogar 1000! Jeder User muss dann in etwa eine halbe Sekunde warten. Und der Server läuft heißer und heißer und immer heißer. Im Ernstfall geht er sogar down.

Und jetzt das Szenario mit einem Thread, der beim ersten Request für den User erzeugt wird und dann erst geschlossen wird, wenn der User das Programm beendet. 10 User stellen wieder ein Request an den Server. Im selbem Takt wie im obrigem Szenario. Alles wird ausgeführt, und da nichts weiter zu machen ist, entstehen keine oder nur Verzögerungen unter 1ms. Dann 100 User: maximal 1ms (mehr als bei 100, aber trotzdem nicht so tragisch). Dann 500 User und zu guter letzt 1000 User. Ich vermute, dass die Verzögerung maximal bei 10ms liegen wird, und auch der Server wird sich abkühlen.

Dies war eine etwas drastische Darstellung, aber meiner Meinung nach ein guter Vergleich.

Mfg Ominion

[EDIT]Mir glaubt es vielleicht keiner, aber als ich angefangen habe zu schreiben, agb es noch keine Antwort.[/EDIT]

Reply to Win32 Threads Designfrage on Sat, 22 Apr 2006 18:22:34 GMT

std**Robin — Sat, 22 Apr 2006 18:22:34 GMT

Hmm, irgendwo im Netz habe ich gelesen, dass es maximal 64 Threads geben kann... Wenn das stimmt wäre das aber ziemlich mager.....

Reply to Win32 Threads Designfrage on Sat, 22 Apr 2006 18:29:16 GMT

~~~~~~~ — Sat, 22 Apr 2006 18:29:16 GMT

std::Robin schrieb:

Hmm, irgendwo im Netz habe ich gelesen, dass es maximal 64 Threads geben kann... Wenn das stimmt wäre das aber ziemlich mager.....

Das ist falsch, vielleicht verwechselst du es mit dem Limit für select().

Reply to Win32 Threads Designfrage on Sat, 22 Apr 2006 18:30:51 GMT

Jochen Kalmbach — Sat, 22 Apr 2006 18:30:51 GMT

Wo hast Du denn das gelesen?
Die Anzahl der Threads eines Prozesses ist aber tatsächlich beschrängt. Und zwar durch den virtuellen Adressraum, da jeder Thread seinen eigenen Stack benötigt). Unter x86 bekommt man somit theoretisch 2 GB / 1024 Bytes Threads erzeugt. Praktisch natürlich nicht, da in diesem 2 GB Adressraum auch noch andere DLLs und Daten/Code liegen. Den 2 GB Adressraum kann man auch noch erhöhen auf 3GB, was dann auch noch was bringt.
Aber prinzipiell kann man sagen: Wenn man so viele Threads benötigt, ist dies ein sehr schelchtes Design, da das OS mehr mit Scheduling beschäftigt ist, als mit "wirklichem" Code!

Reply to Win32 Threads Designfrage on Sat, 22 Apr 2006 18:58:46 GMT

std**Robin — Sat, 22 Apr 2006 18:58:46 GMT

Okay, damit ist meine erste Frage zur vollsten Zufriedenheit beantwortet. Vielen Dank!

Das wirft aber nun eine neue Frage auf.
Ich hatte ja schonmal zur Threadkommunikation einen Topic eröffnet, aber ich werde den Code nun umschreiben und dann passt die Lösung aus dem alten Topic nicht mehr.

(Hier: http://www.c-plusplus.net/forum/viewtopic-var-t-is-144748.html)

Ich mich mal selber zum Thema Threadkommunikation umgeschaut und bisher sehen mir Windowsevents und Messages vielversprechend aus, zumal das warten darauf keine CPU-Last erzeugt....

Leider verstehe ich das noch nicht so ganz ... gibt es vielleicht eine Dokumentation, idealerweise mit Beispielcodes in deutsch?

Gruss
R

Edit das mit den 64 stammt von hier: http://www.tutorials.de/forum/c-c/229169-threads-waitformultipleobjects-wartet-nicht-wenn-ich-ueber-64-threads-starte.html

Zitat:

nCount
Specifies the number of object handles in the array pointed to by lpHandles. The maximum number of object handles is MAXIMUM_WAIT_OBJECTS.

Und MAXIMUM_WAIT_OBJECTS ist 64.

Reply to Win32 Threads Designfrage on Sat, 22 Apr 2006 19:08:12 GMT

Jochen Kalmbach — Sat, 22 Apr 2006 19:08:12 GMT

std::Robin schrieb:

Edit das mit den 64 stammt von hier: http://www.tutorials.de/forum/c-c/229169-threads-waitformultipleobjects-wartet-nicht-wenn-ich-ueber-64-threads-starte.html

Zitat:
nCount
Specifies the number of object handles in the array pointed to by lpHandles. The maximum number of object handles is MAXIMUM_WAIT_OBJECTS.
Und MAXIMUM_WAIT_OBJECTS ist 64.

Und was hat das mit Threads zu tun!?

Reply to Win32 Threads Designfrage on Sat, 22 Apr 2006 19:23:39 GMT

std**Robin — Sat, 22 Apr 2006 19:23:39 GMT

Hat es nicht?
Ich dachte Betriebssystemintern seien Threads Objekte und wenn der Objekthandler auf 64 limitiert ist kann man halt nur auf 64 Objekte warten...
Kann aber auch gut sein, dass ich total daneben liege..

Gruss
R

Reply to Win32 Threads Designfrage on Sat, 22 Apr 2006 19:44:03 GMT

Jochen Kalmbach — Sat, 22 Apr 2006 19:44:03 GMT

std::Robin schrieb:

Hat es nicht?

Nein, hat es nicht.

std::Robin schrieb:

Ich dachte Betriebssystemintern seien Threads Objekte und wenn der Objekthandler auf 64 limitiert ist kann man halt nur auf 64 Objekte warten...

Wenn "WaitForMultipleObjects" limitiert ist, heisst es ja noch lange nicht, dass alles andere (was z.B. nicht warten muss) genauso limitiert ist...