|
|
Betriebssysteme-Blog
Ihre Fragen sind in normaler Schrift dargestellt, meinen Antworten kursiv.
| Praktikum 7: sleep für Thread oder Prozess? (14.07.2008) | |
Laut dem beigelegten Artikel legt ein sleep() den gesamten Prozess
inkl. allen enthaltenen Threads schlafen. usleep(), wie bei uns genutzt
müsste doch den gleichen Prozess weiten Effekt haben. War es in
der Praktikumaufgabe gewollt, den gesamten Prozess schlafen zu legen? Der
Aufruf weckt so ein bisschen den Eindruck als würde er nur den Thread
selbst betreffen.
In den Kommentaren ist noch eine Kleinigkeit, die vielleicht noch
nicht entdeckt worden ist. Laut manpages benötigt usleep() die Anzahl
der Mikro-Sekunden anstatt der Milli-Sekunden.
Hmmmm.... Zu sleep und usleep gibt es zwei Manpages. Rufen Sie mal
"man 3p usleep" und im Vergleich dazu "man 3 usleep" auf; das Handbuch 3p
gibt die POSIX-Anleitungen, und da ist von Threads die Rede.
Das Code-Beispiel im Praktikum geht davon aus, dass nur der Thread
schläft. (hge)
[ Pfad: | permanenter Link ] | |
| Deadlock-Erkennung, bs-ss2008-esser-10-4up.pdf, Folie 17 (14.07.2008) | |
War das "<", statt einem "<=" wirklich beabsichtigt?
(Schließlich sollte der Prozess/Kunde auch gleich die volle Summe von
122 fordern können.) Ich vermute ich sehe ihren Punkt. Im Falle von 122
müsste der Prozess/Kunde bereits alle Resourcen wieder zurückgeben was
das System auf jeden Fall in einen sichereren Zustand bringen würde und
die Prüfung hinfällig machen würde.
Es ist hier egal, weil ja aus "<" auch "<=" folgt. (hge)
[ Pfad: | permanenter Link ] | |
| Prioritätsinversion (14.07.2008) | |
Tritt eine Prioritäteninversion nicht schon mit nur 2 Prioritätsstufen
auf. In der Folie sind zwar 3 Warteschlangen beschrieben, aber müssten
eine hochpriorisierte, welche den betroffenen Thread inkl. aller anderen
dauerlaufenden Threads beinhaltet, und eine niederpriorisierte, welche
den Resourcenblockierenen Thread beinhaltet, nicht schon für eine solche
Situation ausreichen?
Ja. Wenn Sie noch mindestens einen weiteren, ausführbereiten Thread in der
obersten Prioritätsstufe haben, dann reicht das aus, denn der läuft dann
permanent und verhindert auch, dass Threads aus der niedrigen Stufe laufen.
Es muss also mindestens einen Thread geben, dessen Priorität echt höher
als die des niedrigen und kleiner/gleich der des hohen ist. (hge)
[ Pfad: | permanenter Link ] | |
| Thread-Zustände (14.07.2008) | |
Swapping ist für Threads natürlich unmöglich, aber wären sleep() und
suspend() nicht für ein Betriebssystem implementierbar? (Schließlich hat
das Betriebssystem eh von jeden Thread einen eigenen Process Control
Block und kann auch erkennen dass es nur ein Thread ist.)
Theoretisch könnte man das machen. Für suspend() müssten Sie dann aber
Benutzern die Möglichkeit geben, Threads über ihre Thread-ID anzusprechen
und explizit zu suspendieren; das ist z.B. bei Linux nicht vorgesehen.
(hge)
[ Pfad: | permanenter Link ] | |
| Threads und Stacks (14.07.2008) | |
Normalerweise wächst ein Stack von der anderen Seite des
Prozessesspeichers auf die Daten zu. Falls man nun aber mehrere Threads
hat, so können nicht alle von der anderen Seite her wachsen, sondern
müssten irgendwo in der Mitte anfangen. Gibt es da irgendeine einfache
Regelung?
Sie müssen irgendeine Aufteilung des generellen Stack-Bereichs vornehmen.
Wenn Sie Kernel-Level-Threads haben, verwaltet der Kernel für jeden
Thread einen separaten Stack (wie bei verschiedenen Prozessen). Wenn Sie
User-Level-Threads haben, muss sich die UL-Thread-Bibliothek darum
kümmern -- das passiert dann nicht im regulären Stack des Prozesses. (hge)
[ Pfad: | permanenter Link ] | |
|
