... ganz ehrlich? Ich finde das NICHT richtig! Es kann gut sein, dass es in TF so ist, aber dann ist es eher purer Aktionismus denn wirkliches Multithreading.
Na ja, wenn man nun aber eine Aufgabe statt von einem von mehreren lösen läßt, ist die erst vollständig erledigt, wenn alle beteiligten fertig sind. Ob man die Kellermauern von einem oder mehreren mauern läßt, die Decke/den Fußboden kann man erst gießen, ich nehme mal Beton, wenn alle mit ihren Mauern fertig sind. Das meinten @eis_os und ich.
ECHTE Paralellität erreicht man nur durch voneinander UNABHÄNGEN Berechnungen/Aufgaben. Punkt.
Da hast Du vollkommen recht.
Aber meistens hat man Abhängigkeiten und es kommt darauf an, wie gut sich ein Problem oder Teilprobleme parallelisieren lassen.
Sobald die Zielfindung durch ist, aktualisiert sie den Wert (das ist auch noch bissl knifflig OS-intern, aber das soll hier mal aussen vorgelassen werden) und die Wegfindung rechnet plötzlich mit diesem Thread. Beide arbeiten völlig unabhängig voneinander, da muss nix aufs andre warten. Das ist Multithreading
Also ist dein Beispiel doch nicht ganz unabhängig. Der "Datenaustausch" von Threads hat mit dem OS nichts zu tun. Die Threads laufen im gleichen Prozess und somit im selben Adressraum. Zwei Threads können lesend und schreibend auf ein und denselben Speicher gleichzeitig zugreifen. Hier kommt dann die vom Programmierer korrekt vorzunehmende Synchronisation des Zugriffs ins Spiel, sonst gibt es Datensalat.
Und richtig echtes Multithreading ist auf nem Computer eh nich wirklich möglich,
Doch. Wenn ich als Programmierer Threads nutze, interessiert mich die Welt außerhalb meines Programms nicht. Ich weiß, dass ich unter Multitasking-Betriebssystemen wie Windows, OS-X, Linux etc. mit meinem Programm nicht allein auf der Kiste bin. Bei einem Singletasking-System sieht das schon wieder anders aus. Im Embedded-Bereich noch einmal.
Was die GPU rendert ist völlig losgelöst von der CPU. Allerdings ist für ein dynamisches interagieren halt immer wieder neuer Input von der CPU nötig. Ändert sich die Ansicht werden die Matrizen geändert und neu zur GPU geschickt, muss ein Objekt animiert werden, also seine Position/Ausrichtung/Größe ändert sich, müssen die Daten erneut zur GPU gehn.
Dein Allerdings zeigt ja, dass die GPU nicht völlig losgelöst von einer höheren Instanz arbeiten kann, die ihr sagt, was zu tun ist. Und darauf bezog ich mich...
Es lässt sich schlicht nicht alles paralellisieren. Irgendwann kommt auch der Punkt, wo es eher Nachteilig wird, wenn man den Sheduler mit 1000 Threads zubombt hat er mehr Overhead durchs umverteilen wie das tatsächlich Arbeit verrichtet wird.
Ich habe auch Vorlesungen drüber gehört und viel wichtiger, ich nutze Threads und Mutexe ausgiebig im TFMM 
Man kann aber auch nicht blind alle Operation auf diesen Daten mit Mutexen absichern. Wenn dauernd nur auf die Freigabe der Mutex gewartet werden muss bremst man sein Programm damit so sehr das man quasi direkt auf Threads verzichten könnte 
