Operációs rendszerek vizsga 2010. január 18.

1. Hasonlítsa össze a folyamat (process) és a szál (thread) fogalmakat, adja meg az egymáshoz való viszonyukat, miben azonosak/hasonlítanak és miben különböznek! Rövid táblázatos összehasonlítást kérünk, nem esszét!

Szoftvertechnikák egyik előadásrészlete elég jól idevág.

2. feladathoz segítség: Mi a prioritás inverzió jelensége?

A szemaforok alkalmazásának egyik nemkívánatos mellékhatása a prioritás inverzió. Adott egy alacsony, egy közepes és egy magas prioritású taszk. Tételezzük fel, hogy először az alacsony prioritású lesz futásra kész. Miután elindult, egy adott ponton lefoglalja a szemafort, majd fut tovább. Ekkor azonban futásra kész lesz a magas prioritású taszk is. A (preemptív) kernel ennek megfelelően ütemezni is fogja. Egy adott ponton a magas prioritású feladat is le szeretné foglalni a szemafort. De mivel az már foglalt, ezért várakozó állapotba kerül. A vezérlés pedig visszaadódik az ekkor egyetlen futásra kész taszkra, az alacsony prioritásúra. Némi idő eltelte után a közepes fontosságú feladat is futásra kész lesz, a kernel ütemezi is, majd futása végeztével folytatódik tovább az alacsony prioritású taszk futása. Egészen addig, amíg el nem engedi a szemafort. Ez a lépés ugyanis futásra kész állapotba hozza a magas prioritású feladatot, amit a kernel ütemez is. Futása során elvégzi azon műveleteket, melyhez a szemafor kellett, majd elengedi azt. Ekkor nem történik semmi, lévén nem vár magasabb prioritású taszk a szemaforra. Miután befejezi futását, visszatér a vezérlés az alacsony prioritású feladatra, így az is be tudja fejezni működését. Figyeljük meg, hogy az alacsony prioritású taszk részben, a közepes prioritású pedig teljes egészében képes volt "beelőzni" a magas prioritásút. Sőt, ha több köztes prioritású feladat is lenne, legrosszabb esetben mindegyik olyan időzítéssel lesz futásra kész, hogy mindegyik hamarabb fog lefutni, mint a legmagasabb prioritású. Ezért nevezik ezt a jelenséget prioritás inverziónak.

5. Rajzolja fel a UNIX folyamatok teljes állapotátmeneti-gráfját és ismertesse az életciklusukat a létrehozástól a megszűnésig! Térjen ki a fontosabb rendszerhívásokra is!

_UNIX 2. diasorból_
%T% az ábra és a folyamatok életciklusa (állapotátmenetek) pont a fontosabb

<img src = "https://wiki.sch.bme.hu/pub/Infoalap/OpReVizsga20100118PrioritasInverzio/UNIX_folyamat_allapotok.gif"/>

Folyamatok életciklusa (állapotátmenetek)

• Létrehozás
  • fork() : új folyamat létrehozása (copy-on-write technika)
  • exec() : új programkód betöltése egy folyamat címterébe
• Futtatás (ütemezés)
  • futó és futásra kész állapotok közötti átmenetek vezérlése
• Futás megállítása
  • várakozás eseményre (önként)
  • felfüggesztés (felhasználó)
  • leállás (önként vagy a kernel)
• Leállás
  • exit()  : rendszerhívással
  • zombi állapot
  • szülő értesítése
  • gyerekek adoptálása

A fork() és az exec() rendszerhívások

• A fork() eltérő értékkel tér vissza a szülő és a gyerek esetében
• Az exec() sikeres végrehajtás esetén nem tér vissza

		  if ((res = fork()) == 0) {
				// gyerek
				exec(...);
				// ha visszatér, exec hiba történt
		  } else if ( res < 0 ) {
				// fork hiba történt
		  }
		  // res = CHILD_PID (>0), szülő kódja fut tovább 

• fork() variációk (címtér használat, szálak többszörözése)
  • clone() (osztott címtér), vfork() (exec), fork1() (egy szál)
• exec() variációk (elérés, argumentumok, környezet)
  • execl(), execv(), execle(), execve(), execvp(), execlp()

A folyamatok családfája

• Folyamatot csak egy másik folyamat tud létrehozni
  • minden folyamatnak van szülője és lehetnek gyerekei
  • a szülő változhat (így a gyerekek listája is)
• A fork() megadja a szülőnek a gyerek azonosítóját (PID)
• Az ős folyamat (init, idle, swapper)
  • minden folyamat őse
  • a rendszer leállásáig fut
  • örökli az árva folyamatokat
  • figyeli bizonyos rendszerfolyamatok meglétét (futását)
• A család fontos
  • a szülő értesítést kap a gyerek folyamat leállásáról (nyugtáznia kell)

Ha valakinek ez nem elég, akkor innen is válogathat a válaszhoz.

-- esoxmoller - 2010.01.20.