26. April 2024, 04:55
Beiträge anzeigen
Diese Sektion erlaubt es dir alle Beiträge dieses Mitglieds zu sehen. Beachte, dass du nur solche Beiträge sehen kannst, zu denen du auch Zugriffsrechte hast.
An einem Festen ort muss dann nur ein Zeiger auf den Rootknoten liegen, bzw. falls man es wie ihr mit Listen macht auf das Head-Element der Liste.
Im großen und ganzen hast du recht dass Threads mit Prozessen gleichzustellen sind aber Threads sind keine kompletten Programme sondern nur teile (ggf. nur einzelne funktionen). Ein Prozess kann mehere Threads beinhalten. Ein thread ist z.B. bei spiele sehr entscheidend, wenn man z.B. die KI, die Physik und die eingaben der Spieler koordinieren muss (sollte ja alles gleichzeitig ablaufen). Somit kann man für solche Zeitkritischen Funktionen einen eigenen Thread erstellen, damit ein Synchrones arbeiten vorgetäuscht wird.
Also nochmal kurz:
Prozess = Programm (bin mir nicht ganz sicher aber beinhaltet glaube mindestens einen Thread)
Thread = Teil eines Programms
Code: [Auswählen]Es gibt Prozesse und Threads.
Jeder Prozess besitzt mindestens einen Thread.
Der Prozess ist die Umgebung, also der virtuelle Adressraum, bei einem Prozesswechsel muss also das Register CR3 verändert werden.
Jeder Prozess "hat" ein Objekt, das diesen repräsentiert. Mit diesem Objekt wird ein Prozess verwaltet, es beinhaltet Angabe über die Prozess ID, die Basispriorität des Prozesses, sowie die zum Prozess gehörigen Threads.
Ein Thread ist ein Faden im Prozess, der zu dessen Ausführung beiträgt.
Jeder Thread benötigt seinen eigenen Stack und seinen eigenen CPU-Status.
Auch jeder Thread "hat" ein Objekt, das diesen repräsentiert und durch den er verwaltet wird.
)
Übersicht
Wiki
Hilfe
Suche
Einloggen
Registrieren
Als das Grundgerüst mit Threads und Prozessen habe ich oben schon beschrieben.
Aber und jetzt kommt es:
es soll zwei priorisierte Warteschlangen geben,
die eine ist gerade aktive und die andere ist die wartende.
Für die priorität eines Threads gilt jetzt, je kleiner desto besser, wie man sie sich diese errechnet, ist erstmal egal.
Sie muss aber größer 0 sein, ein Thread mit der Priorität würde bei diesem Konzept in Echtzeit laufen, das heißt der Scheduler würde ihn (sogut wie) niemals "absetzen".
Also jeder Thread erhält wieder eine dynamische Priorität, diese wächst aber und sinkt nicht, dafür werden Threads mit möglichst kleiner Priorität bevorzugt.
Es kommt immer der Thread zum Zuge, der die niedrigste dynamische Priorität hat, seine dynamische Priorität wird dadurch, aber um seine Priorität erhöht (das heißt bei niedriger Prioritätszahl, gelangt man nicht so schnell nach oben, wie mit hoher und damit kriegt man öfter die CPU).
Ist ein Thread bei einem vordefinierten Wert angelangt z.b. 256 kommt er in die wartende Warteschlange und erhält eine dynamische Priorität von 0.
Auch ein neuer Thread oder einer, der aus seiner Blockierung erwacht, kommt in die wartende Warteschlange und erhält eine dynamische Priorität von 0.
Sind in der aktiven Warteschlange keine Threads mehr enthalten, werden beide Warteschlangen vertauscht.
Kriterien für die priorisierung in den Warteschlangen, sind wie schon erwähnt die dynamische Priorität an erster stelle (kleiner ist höher) und die konstante Priorität an zweiter Stelle (auch hier kleiner ist höher).
problematisch bei diesem Modell ist, das Threads, die oft blockiert werden, wie solche, die Eingabedaten empfangen im Nachteil sind, da sie nach einer Blockierung immer wieder in der wartenden Warteliste landen.
Ein Ansatz dafür, wäre falls die Threads noch wieder auf die CPU-wartend werden, bevor die Warteschlangen vertauscht worden, sie mit der dynamischen Priorität unter der sie blockiert wurden (bzw. dem maximum ihrer damaligen dynamischen Priorität und der dynamischen Priorität, des aktuell aktiven Threads, damit sie keinen zu großen Vorteil erhalten), wieder in die Warteliste einfügt, was in den meisten Fällen bewirkt, das die Threads sofort wieder zum Zuge kommen.
Falls die Listen zwischenzeitlich gewechselt wurden, könnten sie mit einer dyn. Priorität des aktiven Threads in die aktive Liste eingefügt werden.
So kämen sie mit einer gerechten Priorität wieder ins Spiel, kämen aber sofort wieder an die Reihe.
Es gibt Prozesse und Threads.
Jeder Prozess besitzt mindestens einen Thread.
Der Prozess ist die Umgebung, also der virtuelle Adressraum, bei einem Prozesswechsel muss also das Register CR3 verändert werden.
Jeder Prozess "hat" ein Objekt, das diesen repräsentiert. Mit diesem Objekt wird ein Prozess verwaltet, es beinhaltet Angabe über die Prozess ID, die Basispriorität des Prozesses, sowie die zum Prozess gehörigen Threads.
Ein Thread ist ein Faden im Prozess, der zu dessen Ausführung beiträgt.
Jeder Thread benötigt seinen eigenen Stack und seinen eigenen CPU-Status.
Auch jeder Thread "hat" ein Objekt, das diesen repräsentiert und durch den er verwaltet wird.
Dieses beinhaltet Angaben, über die Thread ID, den CPU-Status, den Zustand des Threads (aktiv/blockiert/wartend/etc.), seine Normalpriorität und seine aktuelle Priorität.
Was hat es nun mit den Prioritäten auf sich und wie wird was verwaltet?
Also, durch Normalpriorität und Basispriorität wird durch Addition dem Thread eine Maximalpriorität zugeordnet.
Bei der Verwaltung geht es um die Zuteilung der CPU-Zeit (Systeme mit mehrern Prozessoren, werden fürs erste außen vor gelassen). Die Verwaltung der CPU-Zeit erfolgt auf Thread-Basis, da sie es sind, die CPU-Zeit beanspruchen.
Alle aktiven Threads werden in einer Priority Queue (priorisierte Warteschlange) verwaltet.
Die Priorität, nach der das entschieden wird, ist die aktuelle Priorität, die sich im Laufe verändert und bei Erzeugung des Threads auf die Maximalpriorität gesetzt wird.
Die CPU-Zeit erhält immer der Thread, der in der Warteschlange ganz vorne steht.
Dieser wird der Warteschlange entnommen (und irgendwo zwischengespeichert).
Die CPU-Zeit wird zerteilt, das heißt z.b. jede 1/512 Sekunde kommt der Scheduler zum Einsatz.
Hierbei, wird die aktuelle Priorität des laufenden Threads dekrementiert (um 1 erniedrigt).
Desweiteren wird überprüft, ob nun ein anderer Thread vorne steht oder der aktuelle Thread blockiert ist.
Der Thread wird in die Liste eingefügt (oder nicht, falls blockiert).
Der neue Thread wird aus der Warteschlange genommen und falls nötig ein CR3-switch durchgeführt und der neue CPU-Status geladen.
Wenn ein Thread Priorität von 0 erreicht, wird zu den aktuellen Prioritäten der aktiven Threads die Maximalpriorität addiert, dies hat Leider einen Zeitaufwand von n * log n, da die Queue neu geformt werden muss, gibt es verbesserungsvorschläge?
) markieren kann, sollte klar sein, der Streit scheint sich ja auch zu legen.
Kernel (Disp, PM, MM)
|
+----+---------- Modulverwaltung (Soft Driver)
| | |
| | Treiberverwaltung (Hard Driver)
| | |
| | z.B. HDD/FDD/CD/Monitor/usw. Treiber (als eigene Prozesse, mit Bibliotheken für Entrypoints
| | |
| +------+----------+
| |
| |
| SoftDriver z.b Dateisysteme (FAT/FAT32/usw.)
| |
+-- kernelinterner Teil der API (zugriff aus SoftDriver/Module)
|
usermode Teil der API (in der Art wie Kernel32.DLL)
|
Programm
grep -c /bin/bash /etc/passwdgrep -l 'DEFINITION MODULE' /programme/*rm -Rf <Verzeichnisname> )Okay, mal was ganz anderes, hier ein kleiner Denkansatz (ist eigentlich doch ziemlich verblüffend):
Angenommen ihr habt eine CPU die genau nur eine einzige Instruktion beherrscht, nennen wir sie Substract And Branch On Less Then Zero.
Die nimmt dann 4 Parameter,
Wert A, Wert B, Ergebnisregister und Branchoffset.
Die Werte A oder B können aber immerhin noch Register oder feste Werte sein.
Wie weit denkt ihr würdet ihr kommen so was zu programmieren?