und begonnen habe, die vielen _beginthreadex und _endthreadex gegen
die gekapselten Methoden einzutauschen, bin ich die ganze Multithreading-
Geschichte noch einmal durchgegangen.
Es lief ein einziger Input-Thread, der peridisch nach Eingabegeräte polled.
Die Daten werden in eine Queue geworfen, allerdings kann mit dem normalen Windows-SDK keine vernünftige zustandsabhängige Steuerung mit wait und notify programmiert werden. (WAS TUN WENN QUEUE VOLL???) Bedingungsvariablen funktionieren auch erst ab Windows Vista (WARUM???), was irgendwie seltsam erscheint, da das Konzept der Threads und die dadurch entstandene Notwendigkeit der Synchronisation sicher schon länger existiert. Anyway, dieser Thread hat zwischendurch gesleept mit 1000 / 30 Millisekunden. Ein Spiel allerdings, das 15-20 FPS erreicht, ist schwer spielbar, also kann dieses Abfragen genauso gut in der normalen Schleife erfolgen.
Der Client war multithreaded, und wurde dann später ebenfalls durch ein Queue-System ausgetauscht. Jedoch werden im Wesentlichen die Daten erst in der Schleife bearbeitet, also wird der Teil auch in die Main-Schleife versetzt werden. However, select zum Beispiel erlaubt das Abfragen, ob Daten vorhanden sind und dieses pollen funktioniert (bereits getestet!) auch periodisch ziemlich vernünftig mit einem Timeout von 0 Millisekunden! Warum also überhaupt threaden?
Es ergeben sich eigentlich nur Nachteile:- Einbruch im Bezug auf die Skalierbarkeit: Thread erzeugen und löschen ist immer noch eine ziemlich kostspielige Aktion, selbst Thread-Pooling wird auch auf Dauer nicht viel helfen, da erst wieder mit Performance-Einbußen zu rechnen ist (bei zb. fiktiv angenommen 1000 Clients!)
- Threads sind eigentlich bei Spielen ziemlich unüblich! Wenn man zum Beispiel das Uralt-Quake hernimmt, glaube ich, dass dieses diverse Netzwerkaktivitäten ohne Threads verarbeitet.
Synchronisationsaufwand! Man darf den Aufwand für das periodische Reservieren und Freigeben der Locks nicht vergessen.
Gefahr von Fehlern! Threads potenzieren die Gefahr von Fehlern, da das nichtdeterministische System eigentlich noch nichtdeterministischer gemacht wird und man überhaupt keine Vorhersage mehr treffen kann, wann etwas durchgeführt wird.
Der Server war multithreaded und wird jetzt wsl. auch vollkommen durch eine iterative Variante ausgetauscht werden. Nachdem Daten verfügbar sind (select!), wird das lesen wsl. sowieso nicht mehr diesen Performanceeinbruch mit sich bringen!
Zusammengefasst: Im Endeffekt werden nach den Veränderungen nicht mehr viele
Threads übrig bleiben!
Keine Kommentare:
Kommentar veröffentlichen