Hallo,
ich wollte mal fragen, wie es sich mit Threads so verhält. Bei einer Software (z.B. ein Art Spiel), macht es sinn jedem Objekt ein Thread zuzuteilen?
Am Ende währen das zu viele Threads die sich gegenseitig stören und die Performance schwächen oder? Da es sich hauptsächlich um asynchrone Threads handeln würde.
Wie würde man aber sonst regeln, oder doch fast jeden Objekt ein Thread zuteilen?
Üblicherweise gibt es bei Spielen einen “Game Thread”, der sich um sämtliche Objekte kümmert. (Und, je nachdem, wie man die Anzeige macht, einen “Grafik-Thread”, z.B. für OpenGL oder Swing).
Die Synchronisation zwischen ZWEI Threads dieser Art kann schon kompliziert genug sein (stichwort ConcurrentModificationException).
Jeder weitere Thread macht das ganze noch schwieriger. Falls es ein hochkomplexes, rechenintensives Spiel sein sollte, könnte man sich überlegen, noch zwischen Dingen wie einem “Physik-Thread” und einem “KI-Thread” zu unterscheiden, oder was man sonst noch machen könnte, um die >=4-8 Cores auszunutzen, die man ja üblicherweise hat. (Aber dass es darum nicht gehen kann, erkennt man schon an der Frage ;-))
Wie Marco bereits angedeutet hat ist die Kommunikation zwischen zwei Threads schwierig und aufwendig.
Erhöht man in der Praxis die Anzahl der Threads erhöht sich die Performance nur asymptotisch.
Man kann sich das gut vorstellen wie beim aufräumen eines Zimmers bei dem die Kreuz und quer liegenden Objekte in die Schränke gepackt werden müssen. Zwei Personen sind nicht doppelt so schnell wie eine, da sie sich gegenseitig blockieren, ausweichen oder aufeinander warten müssen bis eine Ablage nicht mehr verwendet wird.
Füllt man den Raum weiter mit Personen so verringert sich die Zeit nicht linear. Der Aufwand (Anzahl Personen) aber steigt linear.
Verteilt man aber die 1000 Personen gleichmäßig auf 1000 vollkommen isolierte aufzuräumende Zimmer ist das weeeeit effektiver.
Was Spiele neben einem Main/Render/Network/Physics Thread auch noch einführen sind Worker-Threads für rechenaufwendige blockierende Algorithmen sehr beliebt z.B. bei Wegfindungsalgorithmen weil das Ergebnis nicht sofort verfügbar sein muss.
Dabei legt man einen Pool von Threads an denen man Rechenaufgaben übergibt und wenn die Rechnung fertiggestellt ist übergibt der Thread das Ergebnis an einen Listener.
Kommt darauf an.
Nebenläufigkeit hat ihren Preis. Prozesse sind Teuer, Threads sind günstiger haben dennoch ihren Preis, Aktoren sind meist noch günstiger als Threads.
Aktoren nutzen auch Threads, diese aber eher auf einer On-Demand-Basis.
So kommt es das traditionell eher ohne oder mit nur wenigen Threads gearbeitet wurde.
Das könnte sich ändern. Zumindest habe ich schon einen Vortrag gesehen, bei dem jemand ein Spiel darauf aufbauend baut. Sah zumindest mal sehr interessant und einleuchtend aus. Hätte es gerne verlinkt, wenn ich nur wüsste wo das war.
Dadurch, das jedes Objekt, seinen Input-Channel hat, ist das was das Objekt macht relativ Simpel zu Programmieren und entspricht eher der Realität in dem Individuen auch selbständig auf externe Ereignisse reagieren. So wie wir uns die Welt vorstellen.
Das Interessante dabei ist, dass ein Objekt, dass hier einen Input-Event bekommt, diesen in einem eigenen Thread abarbeiten kann. Inneren Zustand ändern ist auch kein Problem, da nur ein Thread darauf zugreift und dieser solange arbeitet, bis alle Events abgearbeitet sind. Und die Kommunikation nach aussen, läuft eben dadurch ab, dass man eben weitere Events an die anderen Objekte verschickt, die dort wiederum Nebenläufig abgearbeitet werden können.
Das ganze ist aber (noch) nicht Main-Stream, so dass Marco und TMII eher die aktuell typische Vorgehensweise verkörpern.
(Zugegeben: “Bei Spielen” war schon sehr allgemein. Schach, Jump’n’Run, AngryBirds oder ein First-Person-Shooter? Aber die Frage war auch sehr allgemein, von daher sollte das passen ;-))
Alles klar. Ich bedanke ich!