Differences

This shows you the differences between two versions of the page.

Link to this comparison view

so:cursuri:curs-04 [2013/01/31 21:57]
127.0.0.1 external edit
so:cursuri:curs-04 [2019/03/09 16:06] (current)
razvan.deaconescu
Line 1: Line 1:
-====== Curs 04 - Planificarea execuției======+====== Curs 04 - Planificarea execuției. IPC ====== 
 + 
 +  * [[http://​prezi.com/​7hdjlraoycrn/​so-curs-4/?​kw=view-7hdjlraoycrn&​rc=ref-31844697|Curs 04 - Planificarea execuției (vizualizare Prezi)]] 
 +  * [[http://​elf.cs.pub.ro/​so/​res/​cursuri/​SO_Curs-04.pdf|Curs 04 - Planificarea execuției (PDF)]] 
 +  * [[http://​elf.cs.pub.ro/​so/​res/​cursuri/​SO_Curs-04_IPC.pdf|Curs 04 - Comunicarea interprocese (PDF)]] 
 + 
 +  * [[https://​docs.google.com/​document/​d/​1s9mWubSu19r4aCThxlDx7MW7uFu3o2v9tSHuvhnfbME/​edit?​usp=sharing|Notițe de curs]] 
 + 
 + 
 +  * Suport curs 
 +    * Operating System Concepts Essentials 
 +      * Capitolul 5 - CPU Scheduling 
 +    * Modern Operating Systems, 2nd Ed 
 +      * Capitolul 2 - Processes and Threads 
 +        * Secțiunea 5 - Scheduling 
 +    * Modern Operating Systems, 3rd Ed 
 +      * Capitolul 2 - Processes and Threads 
 +        * Secțiunea 2.4 - Scheduling 
 +    * Linux System Programming 
 +      * Capitolul 9 - Signals  
 +    * Windows System Programming  
 +     * Capitolul 11 - Interprocess Communication
  
 <​html>​ <​html>​
-<iframe src="​https://​docs.google.com/present/embed?id=dgbccfz4_818cn6d4nc4&size=m" frameborder="0" width="​555" height="​451"></​iframe>​+  <​center>​ 
 +    ​<iframe src="​https://​prezi.com/embed/​7hdjlraoycrn/​?bgcolor=ffffff&amp;​lock_to_path=0&​amp;​autoplay=no&​amp;​autohide_ctrls=0&​amp;​features=undefined&​amp;​disabled_features=undefined" width="​550" height="​400" frameBorder="​0"></​iframe
 +  </center>
 </​html>​ </​html>​
  
-  *[[https://​docs.google.com/​present/​view?id=dgbccfz4_818cn6d4nc4 | Curs 04 - Vizualizare]] +<​html>​ 
-  *[[https://docs.google.com/present/edit?​id=0AXh5Op_iFi3jZGdiY2NmejRfODE4Y242ZDRuYzQ | Curs 04 Editare]]+  <​center>​ 
 +    <iframe src="https://​docs.google.com/​viewer?url=http://​elf.cs.pub.ro/​so/​res/​cursuri/​SO_Curs-04_IPC.pdf&​embedded=true"​ width="​600"​ height="​480"​ style="​border:​ none;">​ 
 +    </​iframe>​ 
 +  </​center>​ 
 +</​html>​ 
 + 
 +===== Demo-uri ===== 
 + 
 +Pentru parcurgerea demo-urilor,​ folosim [[http://​elf.cs.pub.ro/​so/​res/​cursuri/​curs-04-demo.zip|arhiva aferentă]]. Demo-urile rulează pe Linux. Descărcăm arhiva folosind comanda<​code bash> 
 +wget http://​elf.cs.pub.ro/​so/​res/​cursuri/​curs-04-demo.zip 
 +</​code>​ și apoi decomprimăm arhiva<​code bash> 
 +unzip curs-04-demo.zip 
 +</​code>​ și accesăm directorul rezultat în urma decomprimării<​code bash> 
 +cd curs-04-demo/​ 
 +</​code>​ 
 + 
 +Acum putem parcurge secțiunile cu demo-uri de mai jos. 
 + 
 +==== Schimbări de context ==== 
 + 
 +Dorim să vedem numărul de schimbări de context (voluntare sau nevoluntare) ale unei comenzi. Pentru aceasta rulăm comanda<​code bash> 
 +/​usr/​bin/​time -v find /var/log 
 +</​code>​ 
 + 
 +Din output-ul comenzii de mai sus, extragem numărul de schimbări de context. Numerele de schimbări de context se găsesc, respectiv, pe liniile care încep cu //Voluntary context switches//, respectiv //​Involuntary context switches//​. 
 + 
 +Rulăm din nou comanda<​code bash> 
 +/​usr/​bin/​time -v find /var/log 
 +</​code>​ 
 +Observăm că acum, la a doua rulare, este semnificativ mai mic numărul schimbărilor voluntare. Aceasta se întâmplă deoarece se realizează,​ la prima rulare a comenzii, caching în memorie pentru date. Adică nu se mai execută operații blocante la dispozitivele de I/O, rezultând într-un număr mai mic de schimbări voluntare. 
 + 
 +==== Schimbări de context pentru rulare cu redirectare ==== 
 + 
 +Dorim să comparăm numărul de schimbări de context pentru o comandă față de varianta acesteia cu redirectarea ieșirii standard la ''/​dev/​null''​. Pentru aceasta rulăm comanda<​code bash> 
 +/​usr/​bin/​time -v find /var/log > /dev/null 
 +</​code>​ 
 + 
 +Ce valori sunt acum afișate pentru cele două tipuri de schimbări de context? 
 + 
 +Întrucât nu se mai lucrează cu terminalul aferent ieșirii standard, nu se execută multe operații blocante și nu se tranferă date generate de comandă în fișier. Rezultă direct un număr și mai mic de schimbări de context (atât voluntare cât și nevoluntare) și o durată de execuție mai mică a procesului. 
 + 
 +==== Modificare prioritate proces ==== 
 + 
 +Dorim să analizăm impactul configurării priorității statice (nice) a sistemului. Pentru aceasta vom porni același proces cu diverse valori pentru nice și vom observa durata de rulare. 
 + 
 +Intrăm în directorul ''​nice/''​ din arhiva cu demo-uri a cursului și parcurgem fișierele ''​cpu.c''​ și ''​start-all''​. Fișierul ''​cpu.c''​ execută operații care țin procesorul ocupat; fișierul ''​start-all''​ este un script care pornește 6 procese cu diverse valori pentru nice. 
 + 
 +Pentru a putea rula, începem prin compilarea programului ''​cpu.c''​ folosind comanda<​code bash> 
 +make 
 +</​code>​ 
 + 
 +Pentru a testa scenariul rulăm scriptul:<​code bash> 
 +./​start-all 
 +</​code>​ 
 +Scriptul va porni 6 procese cu valori diferite pentru ''​nice'':​ 
 +  * 2 procese vor fi prioritare (''​nice = -20''​);​ 
 +  * 2 procese vor avea prioritate medie (''​nice = 0'',​ implicit);​ 
 +  * 2 procese vor fi subprioritare (''​nice = 19''​). 
 + 
 +Pentru fiecare proces, este reținut output-ul într-un fișier. Pentru a afla timpul fiecărui proces în fișierul rezultat, folosim comanda:<​code bash> 
 +grep -H '​Elapsed'​ pri* 
 +</​code>​ 
 + 
 +Observăm că procesele prioritare au avut cel mai scurt timp de rulare iar cele subprioritare cel mai lung timp. Planificatorul a ținut, așadar, cont de valoarea priorității statice (''​nice''​). 
 + 
 +==== Durată timp de așteptare în coada READY (yield) ==== 
 + 
 +Vrem să vedem cât timp durează pentru un proces să stea în coada READY. Pentru aceasta forțăm trecerea procesului din starea RUNNING în starea READY; ulterior, când va veni rândul său, procesul va fi planificat și va fi trecut din nou în starea RUNNING. 
 + 
 +Forțarea trecerii procesului din starea RUNNING în starea READY se face cu ajutorul apelului ​[[http://man7.org/linux/man-pages/​man2/​sched_yield.2.html|sched_yield]]. Acesta eliberează procesorul curent și trece procesul în starea READY. Dacă nu există alt proces în starea READY, procesul curent va fi replanificat practic instant înapoi pe procesor. 
 + 
 +Intrăm în directorul ''​yield/''​ din arhiva cu demo-uri a cursului și parcurgem fișierele ''​yield.c''​ și ''​run-many''​. Fișierul ''​yield.c''​ execută operații care țin procesorul ocupat apoi apelează ''​sched_yield'';​ în momentul apelării ''​sched_yield''​ procesul este trecut din starea RUNNING în starea READY; în momentul în care procesul revine din ''​sched_yield'',​ a fost replanificat,​ adică retrecut din starea READY în starea RUNNING; se rulează 10 runde. Fișierul ''​run-many''​ este un script care pornește mai multe procese ''​yield'';​ numărul de procese pornite este argumentul primit ca parametru. 
 + 
 +Pentru a putea rula, începem prin compilarea programului ''​yield.c''​ folosind comanda<​code bash> 
 +make 
 +</​code>​ 
 +În urma compilării obținem executabilul ''​yield''​. 
 + 
 +Ca să pornim mai multe procese din executabil, rulăm pe rând scriptul ''​run-many''​ cu un număr crescător dat ca parametru:<​code bash> 
 +./run-many 1 
 +./run-many 2 
 +./run-many 3 
 +./run-many 4 
 +./run-many 5 
 +</​code>​ 
 + 
 +Pentru rulările de la început durata apelului ''​sched_yield''​ (adică tranziția RUNNING -> READY și înapoi READY -> RUNNING) este de 1-2 microsecunde. Practic este instantă schimbarea. De la o anumită valoare primită ca argument durata crește semnificativ pentru anumite apeluri (de ordinul miilor de microsecunde). 
 + 
 +Motivul acestei creșteri este atingerea numărului de procesoare/​core-uri ale sistemului. Fiecare core/​procesor are coada proprie READY. Dacă se creează un număr de procese mai mic sau egal cu numărul de procesoare/​core-uri ale sistemului atunci nu există competiție pe procesor; un proces este trecut în starea READY și apoi revine imediat în RUNNING. 
 + 
 +În momentul în care există unele core-uri care au alocate mai multe procese atunci un proces în READY va aștepta ca un alt proces din RUNNING să elibereze procesorul (fie prin yielding, fie prin blocare, fie prin expirarea cuantei). De aici se observă creșterea duratei apelului ''​sched_yield''​.
  
-  *Suport curs +Durata apelului ''​sched_yield''​ este timpul de așteptare al procesului (//waiting time//), timp care se dorește să fie cât mai mic.
-    *Operating System Concepts +
-      *Capitolul 5 - CPU Scheduling +
-    *Modern Operating Systems +
-      *Capitolul 2 - Processes and Threads - Secțiunea 5 - Scheduling +
-  *[[:​cursuri:​curs-04:​quiz | Quiz curs 04]]+
  
-/* +==== Folosire pipe-uri ====
-===== Răspunsuri întrebări curs ===== +
-  -  +
-    * Scade timpul de răspuns. Procesele pot fii preemptate și în cod kernel în cazul in care unui proces îi expiră cuanta sau îi scade prioritatea. \\ +
-    * Scade productivitatea (throughput-ul) pentru că exista mai multe schimbari de context. +
-  - Corectitudinea (fairness) presupune schimbări dese de context pentru a asigura ca fiecare proces cu aceeași prioritate primește partea sa de procesor. Cum am menționat și la exercițiul precedent, schimbările dese de context scad productivitatea (throughput-ul). +
-  - Shortest remaining time first - când un nou job este submis pentru execuție și timpul de execuție al acestuia este mai mic decât timpul rămas din execuția jobului curent => jobul curent este suspendat și noul job este executat.\\ Notăm cu [a,b] timpul in care un job este activ pe procesor și (a,b) timpul in care un job așteaptă. +
-    * Job1 - [0,3] (3, 15) [15, 22] => TT(1) = 22 ( tstart = 0 tstop = 22 ) +
-    * Job2 - [3,6]                  => TT(2) = 3  ( tstart = 3 tstop = 6 )  +
-    * Job3 - (3,6) [6, 10]          => TT(3) = 7  ( tstart = 3 tstop = 10) +
-    * Job4 (5,10) [10, 15]        ​=> TT(4) 9  ( tstart ​6 tstop 15) +
-  *+
  
-~~DISCUSSION:​off~~+Dorim să creăm un exemplu simplu de folosire a pipe-urilor anonime pentru comunicare între procese înrudite.
  
 +Intrăm în directorul ''​pipe/''​ din arhiva cu demo-uri a cursului și parcurgem fișierul ''​pipe.c''​.
so/cursuri/curs-04.1359662221.txt.gz · Last modified: 2013/03/10 17:49 (external edit)
CC Attribution-Share Alike 3.0 Unported
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0