Lowlevel
Lowlevel => OS-Design => Thema gestartet von: SSJ7Gohan am 23. December 2005, 23:51
-
Hi,
ich bastel grad an meinen Multitasking rum, und habe da ein Problem: Die Informationen über meine Tasks sind in verschiedenen strukts gespeichert. Ich habe jetzt mehrere Funktionen, die diese structs verändern. (z.B. thread_create(), thread_suspend()) Mein scheduler muss diese structs jedoch auch ändern, um den nächsten Task auszusuchen. Deshalb muss sichergestellt werden, das nur ein Thread die structs ändern kann. Bei einem Ein-Prozessorsystem ist das ja ganz leicht: man kann einfach man schaltet einfach die Interrupts ab, wärend man die Daten ändert. Auf einem Multiprozessorsystem funktioniert das ganze aber nicht mehr, da man die anderen Prozessoren die Daten immernoch ändern könnten. Wenn man jedoch die structs mit einem Spinlock schützt, und ein Interrupt tritt wärend des schedulens auf, wird wieder der scheduler aufgerufen, der das Spinlock nicht mehr locken kann, da es ja schon von einem anderen Thread gelockt ist. Fällt jemandem vieleicht eine Methode ein, wie ich dieses Problem lösen kann?
-
Nun, da hab ich mal die Frage - wieso ändert der Scheduler da was?
Und evtl. könnte man ja verschiedene Listen per Prozessor haben. Dann hilft auch das IRQ abschalten wieder was, wenn ich jetzt nichts übersehe.
-
Für jede Prioritätsstufe habe ich eine Linked List, der scheduler wählt aus, welche Prioritätsstufe als nächstes drankommt, holt sich auf der Liste einen Thread und schreibt ihn wieder ans Ende der Liste.
Naja, verschiedene Listen bringen ja auch nichts, da ja z.B. ein Thread auf Prozessor0 auch einen Thread auf Prozessor1 erstellen könnte usw.
Naja, ich bin eben selbst auf die Lösung gekommen, sie ist eigentlich ganz simpel: Man schaltet die Interrupts ab, und lockt ein Spinlock. Threads auf anderen Prozessoren können die Listen nicht ändern, da sie den Spinlock nicht haben, und der "lokale" Prozessor kann beim scheduling nicht unterbrochen werden, da die IRQs für ihn aus sind.
-
Zu diesem Problem gibts einige Lösungsansätze in "Moderne Betriebssysteme" von Andrew S. Tanenbaum. Sowieso sehr empfehlenswertes Buch, wenn auch schon etwas veraltet (bei uns gibts das in großer Stückzahl auch in der Uni-Bibliothek).
-
Manche Dinge ändern sich eben dann doch nicht soo schnell. ;)
-
Außerdem gibt es das Buch schon in der 2. Ausgabe. Die ist von 2001. Zwar immer noch 5 Jahre, aber es werde aktuelle Standards in UNIX und Windows 2000 behandelt. (Sogar mit Fallstudie am Ende für jedes dieser OS)
Ich habe es noch nicht ganz durch, aber behandelt wirklich aktuelle Algorithmen und "Features" von modernen Betriebssystemen.
Und ehrlich gesagt: Hat sich in den letzten fünf Jahren viel bei UNIX/Linux oder Windows getan?
-
Designtechnisch bei beiden eigentlich nix ...
-
Ich sags mal so: da die meisten Konzepte eh schon bis zu 40 Jahre auf dem Buckel haben kann so ein Buch nicht wirklich veralten ^^