fdsonne schrieb:
Wenn du nur zwei eine Ebene höher setzt und diese gleichzeitig die selben Ressourcen beanspruchen, bleibt das Verteileproblem weiterhin vorhanden. Was hast du damit gekonnt? Nix...
Dann hast du aber erst mal "nur" noch 2 Threads, die in Konkurrenz stehen und nicht 100. Das ist ein bedeutender Unterschied.
fdsonne schrieb:
Du verstehst scheinbar das Problem nicht. RR bedeutet 50% links, 50% rechts. Das ist keine Prio, sondern das ist ein gleichsames Verteilen von 100% Ressourcen zu möglichst gleichen Teilen. Am Ende hast du damit gar nix gekonnt.
Wenn zwei Threads die gleiche Prio haben, bleibt nichts anderes übrig, als 50/50 zu machen. Das ist doch offensichtlich.
fdsonne schrieb:
Es bleibt beim Problem, dass der "Verteiler" nicht weiß ob A jetzt wichtiger als B ist wenn beide meinen die selbe Prio rein geschrieben zu haben. Und das ist zwangsweise so, wenn völlig unabhängige Entwickler ihren eigenen Kram zusammen coden.
Deswegen soll ja an den Threads ein Tag oder sonst was dran, damit dann am Ende häufig eben nicht zwei vermeintlich gleich wichtige Threads gegeneinander stehen, sondern der Wichtigere bevorzugt wird. Auch die unabhängigen Entwickler verstehen, dass das sinnvoll ist.
fdsonne schrieb:
Bitte erklär doch mal wie das gehen soll? Das funktioniert nicht, wie ich dir nun x-fach aufgezählt habe. Das geht bestenfalls auf eine Art "Wunschliste" hinaus. Aber der, der letzlich entscheidet wer welche Ressourcen nutzen darf ist OS Seitig der Threadscheduler, der hat aber keine Deutungshoheit in der Form, dass er weis was der Anwender will.
Der Anwender bestimmt über sein Verhalten, was ihm wichtiger ist. Vordergrundprozessen (im Sinne von nicht-Hintergrunddienste) wird heute schon im Standardfall eine höhere Priorität gegeben. Das kombiniert mit den zuvor erwähnten Tags, die Programmierer vorgeben, sollten für den Scheduler genug Informationen geben.
Wenn du dann ein Spiel zockst und gleichzeitig renderst, dann bekommt das Spiel bevorzugt Rechenzeit. Der Rendervorgang dauert dann länger, dafür läuft das Spiel dann aber flüssiger.
Vielleicht liegt hier ein Missverständnis vor. Ich schlage zusätzlich zu den Prios ein Tag-System vor, über das der Scheduler (ungefähr) weiß, was der Thread für Arbeit macht und welche Ressourcen er benötigt. Hat er dann zwei Threads, z. B. einer ist mit Integer- und der andere mit Gleitkommaberechnung getaggt, dann weiß der Scheduler, dass er diese Threads gleichzeitig auf einem echte Core mit HT laufen lassen kann. Sie nutzen ja unterschiedliche Rechenwerke. Haben zwei Threads den Integer-Tag, dann weiß der Scheduler, dass sie nicht auf einem Core harmonieren werden.
Eine IDE kann den Programmierern hier sicher Hilfestellungen geben und bei der Codeanalyse gewisse Sachen Tags vorschlagen oder gleich automatisch setzen. Oder auch warnen, dass ein Thread zu viel Tags hat, um sinnvoll vom Scheduler eingetaktet werden zu können.
