PureBoard

Wenn man eine Prozedur als Thread startet wird die ja parallel zum "Restprogramm" ausgeführt. (Wahrscheinlich stimmt das so nicht.)

Warum macht man dann nicht alles mit Threads? Zum Beispiel um mehrere Dateien gleichzeitig zu laden, oder komplizierte Rechnungen auszuführen?

Windows gibt jedem Programm eine Zeitscheibe, so das alle mal ausgeführt
werden (unter Berücksichtigung von Prioritäten). Bei Threads wird Dein
Programm nochmals in Zeitscheiben unterteilt. Da die einzelnen Threads sich
aber einen Speicher Teilen (jedes Programm erhält seinen eigenen virtuellen
Speicher), kann es leicht zu Überschneidungen kommen. Dies zu verhindern
ist nicht ganz so einfach, deshalb nutzt man Threads auch nur selten und nur
in Situationen, wo es wirklich sinnvoll ist.

Ich hab zum Beispiel im Internet gelesen, dass man bei Spielen, in der Art:

""

die spielerbewegung() und die computerbewegung() in threads packen würde.
Stimmt das?

>> Stimmt das?
Das kann man so Pauschal nicht beantworten. Es müßte sichergestellt
werden, das sich da nichts ins Gehege kommt, weil sich Pointer oder
Variablenwerte ändern. Oftmals ist es einfacher und sicherer diese
Timergesteuert aufzurufen

> Ich hab zum Beispiel im Internet gelesen, dass man bei Spielen, in der Art:

da kommt es auch noch darauf an, in welcher sprache.
wo hast du das denn gelesen?

grundsätzlich spricht nichts dagegen, das in threads aufzuteilen,
wobei ich dann eher sagen würde, dass der thread Spielersteuerung()
nur die abfrage von maus und tastatur beinhaltet.
die bewegungen der Figuren stecken dann komplett in Computersteuerung(),
und zumindest dieser thread muss exakt timer-gesteuert sein,
weil er die spielgeschwindigkeit bedeutet.

die komplette bildschirmausgabe in einem thread zu haben, ist eigentlich eine gute lösung,
weil sich dann die ausgabe an der framerate orientieren kann,
aber die spielgeschwindigkewit davon nicht beeinflusst wird.
d.h. wenn eine einheit von A nach B 20 sekunden braucht, dann braucht sie solange,
egal, ob zwischendrin mal die framerate auf 9FPS runtergeht.

ts-soft hat geschrieben:Es müßte sichergestellt
werden, das sich da nichts ins Gehege kommt, weil sich Pointer oder
Variablenwerte ändern.

Das lässt sich seit PB 4.00 doch mittels den Mutex-Befehlen verhindern

Ansonsten: Z. B. macht es keinen Sinn, Dateien einzeln in getrennten Threads zu laden, da sie oftmals nicht goß genug sind, als das es sich lohnen würde. Oder Daten werden nicht in der richtigen Reihenfolge geladen, weil der Benutzer gerade ein anderes rechenintensives Programm offen hat, welches dazu führt, dass deine Threads nicht wie erwartet gestartet/beendet werden. Sie mal bei CreateMutex() (das Consolenbeispiel) nach, damit du besser verstehst, was ich meine, obbba.

Es macht keinen sinn alles mit Mutexen gegeneinander abzuschotten (dann brauch man auch keine Threads verwenden, dann ist es nämlich nicht schneller), man sollte nur sicherstellen, das etwas nicht verändert wird, während es gelesen wird oder das mehrere Threads gleichzeitig auf werte zu schreiben versuchen, wenn es sich dabei um nichtatomare daten handelt (zb quads).

Der grund warum man nicht einfach alles mit Threads macht ist der, dass das sehr schwer auffindbare Fehrler produzieren kann. Man sollte Threads nur verwenden wenn man weiß was man tut.

Wenn mehrere CPUs zur verfügung stehen oder eine CPU Hyperthreading fähig ist, kann ein Programm aber deutlich schneller werden wenn man Threads verwendet.

Zaphod hat geschrieben:... wenn man weiß was man tut.

AMEN

...gilt eigentlich fürs alles im leben...

createMutex gibt's bei mir nicht (PB-Demo).
Und ich hab das bei C oder C++ gelesen. Da war auch die rede davon, das "Anzeige()" in einen thread kommen würde.

Was heißt Timergesteuert? Ich hätte das dann so gemacht, das die Funktion, die zuerst fertig ist auf die anderen wartet. Meint ihr das?

Und die Variablen, die übergeben werden müssten, kommen dann in einen reservierten Speicher, auf den dann die anderen Funktionen zugreifen.

nein, dann braucht man keine threads, das würde deine kompletten bemühungen unterminieren.

der Units-Bewegungs-Thread Computersteuerung() ist timergesteuert,
d.h. er läuft streng mit einer bestimmten anzahl an durchläufen pro sekunde,
was dazu führt, dass sich alle einheiten gleichmäßig schnell bewegen.

wenn man die tastatur/maus-abfrage in einem extra-thread hat,
kann man den so-schnell-wie-möglich durchlaufen lassen,
(natürlich trotzdem nicht auf 100% CPU)
um immer die aktuellen infos zu haben bzw. um eine art tastaturpuffer zu etablieren.

der Anzeige-Thread wiederum läuft mit der Framerate, die möglich ist,
richtet sich also optimal nach der Hardware.
wenn mal viele texturen und objekte im Bild sind, kann die Framerate runtergehen,
wenn wenig los ist, boostet sie mal.

aber die eigentliche spielgeschwindigkeit wird von der framerate nicht beeinflusst, weil die timergesteuert läuft.