Ing.

Gabriele MONTI 1999 - 2006

Processi

www.ingmonti.it

I processi e la loro gestione

Q ello !i "rocesso # n concetto astratto$ come e%i!en&iato !alla bella !e'ini&ione !i Tanenba m( Processo: l'astrazione di un programma che sta girando. )a reali&&a&ione "ratica !i * esto concetto astratto ric+ie!e( - il co!ice macc+ina !el "rogramma !a eseg ire - i !ati !el "rogramma - na str tt ra !ati tile al ,ernel !el -.O. "er la gestione !el "rocesso ./!escrittore !i "rocesso/0 Il -.O. !o%r1 tenere traccia !i t tte le in'orma&ioni necessarie "erc+2 ogni "rocesso sos"eso "ossa ri"ren!ere l3esec &ione * an!o %err1 il momento !i 'arlo. 4rea&ione !ei "rocessi 5n "rocesso esiste * an!o il s o co!ice e! i s oi !ati sono gi1 stati caricati in memoria e! il s o !escrittore # stato creato. 6l momento !ella crea&ione !i ogni "rocesso a! esso %iene associato n n mero ni%oco$ c+e %err1 sato in seg ito come /c+ia%e/ "er ri'erirsi a * el "rocesso. In 5ni7 * esto n mero si c+iama Process I!enti'ier$ o "rocess I8 .PI80. 4onoscere il PI8 !i n "rocesso # in!is"ensabile se gli si %ogliono s"e!ire !ei messaggi. 4ome accennato nel ca"itolo "rece!ente$ n 'ile contente n "rogramma " 9 !are origine a molti "rocessi !i%ersi$ !ato c+e$ in n sistema m lti"rogrammato$ ogni tente " 9 lanciare na o "i: co"ie !elle stesso "rogramma. 4iasc na !i * este co"ie genera n "rocesso !i%erso anc+e !agli altri "rocessi c+e eseg ono lo stesso "rogramma. Pren!en!o in "restito la terminologia !ella "rogramma&ione a! oggetti si "otrebbe !ire c+e il "rogramma # na /classe/$ mentre n "rocesso # n3/istan&a/ !ella classe. 8 n* e n "rocesso # na !elle tante "ossibili istan&e in esec &ione !i n "rogramma$ na /istan&a/ 1 !el "rogramma mentre gira.

;ig ra 1( lo stesso "rogramma eseg ito !a tre "rocessi !i%ersi

1 atten&ione$ * esto termine %iene sato nella "rogramma&ione a! oggetti con n signi'icato !i%erso !a * esto<

02 "rocessi.o!t

=er. 0.>.1 2012-0?-2>

". 1 !i 10

 Ing. Gabriele MONTI

www.ingmonti.it

)a ;ig ra 1 mostra tre "rocessi c+e eseg ono lo stesso "rogramma in )in 7$ nelle 'inestre .10 $ .20 e .@0. Il "rogramma # /%i/$ n sem"lice e!itor !i testi. 4iasc na !elle tre 'inestre mostra lo stato !i n "rocesso !i%erso$ la 'inestra .?0 mostra il ris ltato !ell3esec &ione !el coman!o !i -.O. "s Aa$ c+e %is ali&&a t tti i "rocessi atti%i in n !eterminato istante. I "rocessi n mero 912$ 91@ e 919 sono i tre "rocessi nelle 'inestre !a 1 a @ e! eseg ono lo stesso "rogramma /%i/. )e tre !i%erse /istan&e/ !i %i sono "eraltro !el t tto in!i"en!enti 'ra !i loro$ in'atti stanno la%oran!o s i tre !i%ersi 'ile "inocc+io.t7t .10$ in'erno.t7t e " rgator.t7t. Per i "rogrammi al !i ' ori !el ,ernel e! anc+e "er la gran "arte !ei "rogrammi !el ,ernel$ ogni "rocesso %e!e na macc+ina %irt ale$ "er c i agisce come se !is"onesse !i na 4P5 e !i na memoria solo "er s2 stesso.
Per esempio in Linux gli unici processi che non hanno memoria virtuale sono i thread interni al kernel ed i "demoni" (daemons):.

-ar1 com"ito !el gestore !ella memoria$ c+e # "arte !el -.O.$ reali&&are n meccanismo "er "roteggere la memoria e 'are in mo!o c+e n "rocesso non "ossa inter'erire con la * ella assegnata a! n altro$ n2 inten&ionalmente$ n2 "er errore. Per reali&&are * esta "rote&ione il -.O. al momento !ella crea&ione !i ogni "rocesso "ro%%e!er1 a riser%argli na "or&ione !ella memoria %irt ale. -e n * alsiasi altro "rocesso non /!i sistema/ tenter1 !i acce!ere alla memoria riser%ata "er il "rocesso a""ena creato esso %err1 terminato !al -.O. In * esto mo!o si # assic rati c+e$ se n "rocesso tenta !i !anneggiare la memoria altr i sar1 solo esso a s birne le conseg en&e$ e non t tto il sistema. Q an!o n "rocesso +a na "or&ione !i memoria %irt ale a! esso riser%ata si s ole !ire c+e il "rocesso /eseg e in n s o s"a&io !i memoria/.

1.1

Stati di un processo

Nei sistemi m lti"rogrammati a 4P5 singola t tti i "rocessi$ tranne no$ sono sos"esi. 5n nico "rocesso # in%ece in esec &ione s lla 4P5. 8 n* e ogni "rocesso " 9 essere almeno in ! e /con!i&ioni/ !i%erse( na con!i&ione .stato0 in c i # in esec &ione e! n3altra nella * ale # sos"eso. Q esto e%i!en&ia na !i''eren&a im"ortante 'ra "rocessi e "rogrammi( n "rocesso +a no stato$ n "rogramma no. In n sistema m lti"rogrammato se n "rocesso +a necessit1 !i na risorsa c+e # att almente im"egnata !a n altro$ esso !e%e essere tem"oraneamente sos"eso$ in attesa c+e la risorsa %enga liberata. Nat ralmente il "rocesso c+e %iene sos"eso !e%e "oter essere /congelato/ e ri"reso in mo!o c+e contin i sen&a into""i. Q an!o n "rocesso %iene sos"eso # "erci9 in!is"ensabile co"iarne in memoria ogni in'orma&ione c+e "ermetta !i ri"ren!erne l3esec &ione come se n lla 'osse s ccesso. )a str tt ra !ati o%e %iene co"iato lo stato !i n "rocesso al momento !i na sos"ensione %iene !etta / descrittore di processo/. Mentre n "rogramma in n -.O. mono"rogrammato non +a la necessit1 !i a%ere n !escrittore$ ogni "rocesso !i n -.O. m lti"rogrammato !e%e a%erne no. Per alc ni !ettagli s lla gestione !ei !escrittori si %e!a nel "rosieg o !el ca"itolo. 8 n* e abbiamo in!i%i! ato ! e /stati/ "er n "rocesso( no stato !i /esec &ione/ e! no !i /sos"ensione/. 4+iamiamo /running/ ./in esec &ione/0 la con!i&ione in c i si tro%a n "rocesso nel momento in c i$ a%en!o !is"onibilit1 !ella 4P5$ sta "roseg en!o nella s a esec &ione. Per lo stato !i /sos"ensione/ # necessario 'are !elle !istin&ioniB in "articolare bisogna e%i!en&iare la ragione "er la * ale il "rocesso # sos"eso. -e il "rocesso +a la !is"onibilit1 !i t tte le risorse tranne la 4P5 ci9 signi'ica c+e "otrebbe "roseg ire normalmente$ se non 'osse stato sos"eso !al -.O. "er "oter lasciar eseg ire n altro "rocesso. 4+iamiamo /ready/ ./"ronto/0 la con!i&ione in c i si tro%a n "rocesso * an!o # "ronto a! eseg ire ma non lo " 9 'are "erc+2 manca tem"oraneamente !ella 4P5. 5n "rocesso "ronto +a t tte le risorse !i c i +a bisogno tranne la 4P5$ " 9 eseg ire in * alsiasi momento$ basta c+e il -.O. !eci!a c+e # il s o t rno. 5n altro caso in c i n "rocesso "otrebbe essere sos"eso # * an!o +a c+iesto al -.O. na risorsa in!is"ensabile "er la s a "rosec &ione e non l3+a ancora otten ta. In * esta con!i&ione il "rocesso non "roseg irebbe nella s a esec &ione anc+e se a%esse la 4P5$ "erc+2 rimarrebbe bloccato in n loo" in attesa !ella risorsa mancante ./b sC waiting/ o /attesa atti%a/0. ". 2 !i 10 2012-0?-2> 02 "rocessi.o!t

 Ing. Gabriele MONTI 1999 - 2006

Processi

www.ingmonti.it

Per * esto t tti i -.O. general " r"ose sos"en!ono i "rocessi c+e ric+ie!ono na risorsa e non li 'anno "i: eseg ire 'ino a c+e non gliela "ossono assegnare. Q esto signi'ica c+e abbiamo in!i%i! ato n n o%o stato !el "rocesso$ nel * ale esso # sos"eso$ ma non " 9 eseg ire 'ino a c+e non s cce!e * alcosa.. 4+iamiamo /blocked/ ./bloccato/0 o /waiting/ ./in attesa /0 la con!i&ione in c i si tro%a n "rocesso * an!o$ "er * alsiasi ragione$ non +a !is"onibilit1 !i na risorsa !i%ersa !alla 4P5 e "er * esta ragione non %iene 'atto eseg ire !al -.O.. Il 'atto c+e n "rocesso abbia * esti !i%ersi stati in!i%i! a anc+e n3altra ' n&ione !el -.O.$ cio# il tener traccia !ello stato !i ciasc no !ei "rocessi. )a "arte !i -.O. c+e s%olge * esta ' n&ione 'a sen&3altro "arte !el ,ernel$ "er c i t tti gli e%enti c+e "ossono 'ar cambiare !i stato n "rocesso !e%ono a%%enire con la 4P5 c+e la%ora in /,ernel-mo!e/. Il "rocesso " 9 c+ie!ere al -.O.$ con na c+iamata !i sistema$ !i essere sos"eso o terminato$ ma !e%e essere il ,ernel$ c+e # il solo a! a%er accesso ai !escrittori !i "rocesso$ a! e''ett are la transi&ione !i stato. 8isegniamo ora n gra'o !egli stati2$ c+e com"ren!a gli stati !i n "rocesso e le relati%e transi&ioni(

Figura 2: grafo degli stati di un processo )a ;ig ra 2 com"ren!e anc+e ! e stati /accessori/ in c i il "rocesso %a a 'inire * an!o # in con!i&ioni "articolari. )o stato /hold/ .attesa !el Dob0 %e!e il "rocesso ' ori !alla memoria in attesa !i essere creato .se %ogliamo essere "ignoli$ in * esta con!i&ione esso non # ancora n "rocesso0. 5n sistema batc+ "otrebbe ritar!are l3esec &ione !ei Dob * an!o # tro""o congestionato$ in * esti casi il Dob "otrebbe rimanere in stato !i +ol!. Molti -.O. non +anno no stato !i +ol!. E stato anc+e !isegnato no stato !i /en!/$ nel * ale il "rocesso gi nge solo "er essere concl so. Fol! AG Hea!C La fase di creazione di un processo indicata dalla transizione fra "hold" e "ready". Viene allocata la memoria per il processo, il relativo programma viene caricato in memoria, viene creato un descrittore di processo ed il processo viene messo in stato di pronto. I processi interattivi non possono stare in "hold", per cui vengono messi subito in stato di ready oppure, se il sistema sovraccarico, vengono rifiutati. La decisione di far passare un job allo stato di ready viene presa da un componente del .!. che si chiama " job scheduler" o "scheduler di lungo termine". Il job scheduler lavora su una coda di job da eseguire in batch e decide in che ordine essi debbono essere eseguiti. La decisione pu" tener conto di molti fattori, che contribuiscono alla massimizzazione del throughput del sistema.

"er la !e'ini&ione !i gra'o si %e!a l3in!ice analitico !el =ol me 1

02 "rocessi.o!t

=er. 0.>.1 2012-0?-2>

". @ !i 10

 Ing. Gabriele MONTI

www.ingmonti.it

Hea!C AG Fol! #uesta transizione viene detta "roll out" e riguarda un job non interattivo che viene temporaneamente scaricato dalla memoria perch$ il sistema congestionato. %i" allo scopo di far terminare gli altri processi e di ricaricare il job escluso &uando il computer pi' libero. i fa notare che in tutti gli stati, tranne che in "hold", il processo rimane in memoria anche &uando non esegue. Hea!C AG H nning Q esta transi&ione "ermette al "rocesso !i a%an&are nella s a esec &ione. )6 4P5 %iene accor!ata al "rocesso !a n sotto"rogramma !el -.O. c+e si c+iama /dispatcher" o /process scheduler /@ ./"iani'icatore/ !ei "rocessi0 e! # no sc+e! ler !i bre%e termine. Il "rocess sc+e! ler +a il com"ito !i scegliere$ 'ra t tti i "rocessi "ronti$ * ello !a man!are in esec &ione. Il %erbo /to sc+e! le/ signi'ica /"iani'icare/ o /"rogrammare/ .nel senso !i /mettere in "rogramma&ione/ o /!eci!ere * an!o si !e%e 'are/ * alcosa0. )a scelta !el "rocess sc+e! ler s * ale "rocesso 'ar eseg ire a%%err1 secon!o "recisi criteri$ %olti a ren!ere "i: e''iciente il com" ter. Il "rocess sc+e! ler %iene c+iamato ogni %olta c+e s cce!e * alcosa c+e 'a cambiare lo stato !i n * alsiasi "rocesso. 4i9 " 9 s cce!ere "er esem"io in conseg en&a !i( - interr "t !el real time cloc, - com"letamento !i a&ioni !i IIO - c+iamate !i sistema - e%enti !i sincroni&&a&ione !ei "rocessi .".es. wait o signal$ %e!i oltre0 H nning AG Hea!C Q esta transi&ione a%%iene anc+e se il "rocesso "otrebbe tran* illamente "roseg ire. E n3a&ione /arbitraria/ !el -.O. c+e !eci!e !i togliere la 4P5 al "rocesso "erc+2 esso l3+a a% ta "er n tem"o s ''iciente o "erc+2 n altro "rocesso "i: im"ortante !e%e eseg ire. -i tratta ! n* e !i na /"reem"tion/$ come !e'inita nel 4a"itolo "rece!ente. Nei sistemi coo"erati%i * esta transi&ione a%%iene solo se il "rocesso ce!e /%olontariamente/ il "asso a! altri "rocessi$ "er assic rare n ' n&ionamento "i: ni'orme !el sistema .es. loo" !i /e%enti/ in Jin!ows @ e K0. H nning AG Lloc,e! Q an!o il "rocesso +a necessit1 !i na risorsa la !e%e c+ie!ere al -.O.$ con na c+iamata !i sistema. Il -.O. inter%iene e! e''ett a na %eri'ica. -e la risorsa # accessibile e! il "rocesso +a il !iritto !i a%erla essa gli %iene allocata. Poi il "rocesso %iene messo in stato !i rea!C$ "ronto a "roseg ire$ o"" re gli %iene restit ito s bito il controllo. -e in%ece la risorsa non # !is"onibile$ allora il "rocesso %iene sos"eso !al -.O. e messo in stato !i bloc,e!$ o%e rimarr1 'ino a * an!o la risorsa non !i%err1 !is"onibile. -e molti "rocessi !e%ono a%ere accesso a! na stessa risorsa il -.O. crea na / coda dei processi/ in attesa !ella risorsa. Q an!o il "rocesso c+e !etiene la risorsa la liberer1$ il -.O. sceglier1 il "rocesso !a mettere in stato !i rea!C$ 'ra * elli in attesa nella co!a. -"esso nel momento in c i n "rocesso si blocca %iene creato o! e%ocato n altro "rocesso c+e !e%e "roc rare la risorsa .".es. se %iene ric+iesta na "arte !i n 'ile si crea n "rocesso !i IIO c+e %a nell3+ar! !is, e legge l3in'orma&ione ric+iesta0. La transizione potrebbe avvenire anche su richiesta del processo, che potrebbe voler "dormire" per &ualche tempo, anche se non ha necessit( di alcuna risorsa. In &uesto caso si sospender( in una coda "degli allarmi" e verr( risvegliato &uando il tempo richiesto sar( esaurito. Lloc,e! AG Hea!C Q an!o la risorsa "er la * ale il "rocesso era stato bloccato !i%iene !is"onibile il -.O. rimette il "rocesso in con!i&ione !i rea!C$ "ronto "er essere scelto !al "rocess sc+e! ler "er il s o "rossimo slice !i esec &ione. )a transi&ione !a Lloc,e! a H nning$ in!icata in ;ig ra 2 !a n arco tratteggiato$ # "ossibile$ ma la s a esisten&a !i"en!e !al -istema O"erati%o. Q an!o n "rocesso "assa in stato !i /Hea!C/ il ,ernel !eci!e se il "rocesso c+e sta%a eseg en!o att almente !e%e essere sos"eso$ "er 'ar eseg ire al s o "osto * ello c+e # a""ena gi nto allo stato !i /"ronto/ ./"reem"tion/0. H nning AG Mn! Q esta transi&ione concl !e il "rocesso. 5n "rocesso si " 9 concl !ere regolarmente$ * an!o c+ie!e !i essere terminato !o"o a%er concl so la s a esec &ione$ ma anc+e /im"ro%%isamente/$ * an!o entra in na con!i&ione !3errore. Per esem"io ci9 " 9 acca!ere * an!o eseg e n3istr &ione o! n accesso alla memoria c+e non gli sono concesse .errore !i "rote&ione0 o * an!o incorre in errori so'tware c+e non " 9 rec "erare .stac, esa rito$ !i%isione "er &ero ..0.

!i solito si inten!e con /!is"atc+er/ * alcosa !i meno /im"egnati%o/ !i n /"rocess sc+e! ler/

". ? !i 10

2012-0?-2>

02 "rocessi.o!t

 Ing. Gabriele MONTI 1999 - 2006

Processi

www.ingmonti.it

Q an!o n "rocesso %iene terminato la memoria e t tte le altre risorse c+e ritene%a %engono liberate e messe a !is"osi&ione !i altri "rocessi. )o stato /en!/ # in!icato "er "oter !ar conto !ella 'ine !el "rogramma. 8ato c+e il "rocesso s bito !o"o %iene eliminato non # !etto c+e %enga e''etti%amente scritto nel !escrittore !i "rocesso.
In Unix esiste effettivamente uno stato di "zom ie"! nel "uale viene posto un processo "uando # finito! per "ualsiasi ragione! ma ha ancora un descrittore di processo! che non # stato cancellato per errore.

Politiche di scheduling dei processi

)o sc+e! ler 'a t tto il "ossibile "erc+2 il sistema sia sato al meglio !elle s e "ossibilit1. 8e%e "erci9 'are in mo!o c+e la 4P5 e! i !is"ositi%i siano costantemente im"iegati$ c+e ness n "rocesso rimanga sen&a essere eseg ito "er molto tem"o$ c+e gli tenti rice%ano ris"oste in tem"i accettabili$ c+e * an!o il sistema # sotto carico estremo le s e "resta&ioni non !eca!ano br scamente ./grace' l !egra!ation/0. Nat ralmente # im"ossibile garantire /matematicamente/ l3ottimalit1 !i t tte le con!i&ioni elencate$ c+e s"esso sono in contrasto 'ra !i loro$ "er c i lo sc+e! ler !e%e cercare b one sol &ioni !i com"romesso$ c+e !iano "resta&ioni accettabili. -i !ice /"olitica/ !i sc+e! ling .sc+e! ling /"olicC/ o /strategC/0 l3insieme !elle tecnic+e tili&&ate !a n -.O. "er !eci!ere l3or!ine !i esec &ione !ei "rocessi. Len si com"ren!e come l3algoritmo !i sc+e! ling !ei "rocessi sia !ecisi%o "er le "resta&ioni !i n -istema O"erati%o$ sia "erc+2 %iene eseg ito molto s"esso$ e * in!i !e%e essere !i %eloce esec &ione$ sia so"ratt tto "erc+2 le s e !ecisioni "ossono "ortare a! na sotto tili&&a&ione !el sistema. )o sc+e! ling !ei sistemi " 9 essere "re-em"ti%e$ non "reem"ti%e e coo"erati%o. In no sc+ema non "reem"ti%e i "rocessi "er!ono la 4P5 * an!o terminano la loro esec &ione o"" re * an!o si bloccano in attesa !i IIO o !i na risorsa. I -.O. con sc+e! ling "reem"ti%e "ossono togliere la 4P5 a! n "rocesso anc+e * an!o esso +a eseg ito "er tro""o tem"o .es. t tti i -.O. in tem"o reale0. -e lo sc+e! ling # coo"erati%o il "rocesso lascia la 4P5 solo * an!o 'a na s"eci'ica c+iamata al -.O. "er ce!ere il controllo. )a "er!ita !ella 4P5 * in!i non !i"en!e n2 !al tem"o c+e il "rocesso +a sato$ n2 !al 'atto c+e esso abbia ric+iesto n IIO. )el corso del tempo sono state sviluppate molte politiche di scheduling, in pratica almeno una per ogni .!. In &uesto paragrafo ne discuteremo alcune delle pi' comuni. ;irst 4ome ;irst -er%e! Il primo che arriva il primo servito* la coda del processi strettamente +I+! ,+irst In +irst !ut-. #uesta politica era usata nei sistemi batch, nei sistemi odierni non viene pi' usata per i processi interattivi, perch$ i processi che usano molto la %./ ,%./ bound- tendono a monopolizzarla. -+ortest Hemaining Time Ne7t Viene eseguito il processo che "finir( primo". #uesta politica prevede di avere una buona stima di &uanto durer( il processo e tende a fare in modo che i processi che sono vicini alla conclusione, oppure &uelli brevi, siano eseguiti prima, in modo che possano liberare prima le loro risorse. #uesto algoritmo in grado di minimizzare il tempo di attesa per l0esecuzione dei processi ed molto valido se si pu" stimare bene per &uanto dureranno i processi1 &uesto molto difficile per i processi interattivi, per cui lo scheduling a "tempo rimanente" viene usato solo per i job batch. Ho n! Hobin #uesta tecnica classica dei sistemi time-sharing. La %./ viene assegnata "a turno", per un numero di &uanti di tempo prestabilito, a ciascun processo, uno alla volta. e il processo alla fine del suo tempo non ancora terminato, o bloccato, verr( sospeso e messo nella coda dei processi pronti. Il %antaggio "rinci"ale !el round robin # c+e la 4P5 %iene s !!i%isa e* amente 'ra i "rocessi. 4i9 im"lica b oni tem"i !i ris"osta "er i terminali interatti%i. Inutile d ire che la durata del &uanto di tempo decisiva per le buone prestazioni del sistema, se troppo breve i troppi cambi di contesto fanno diminuire l0efficienza del sistema, se troppo lunga il ritardo di risposta dei terminali interattivi potrebbe divenire inaccettabile. Priorit1 #uesto metodo, detto anche "scheduling event driven", prevede l0assegnazione di una priorit( ad ogni processo. .oi, ogni volta che il dispatcher interviene, sceglie per l0esecuzione il processo pronto con la migliore priorit(. Il maggior problema di &uesto approccio che i processi con cattiva priorit( possono essere scavalcati continuamente da &uelli pi' importanti, fino a correre il rischio di non eseguire mai, &uando il sistema sotto carico estremo ," starvation" 2 morte per fame3-. .er ovviare a &uesto problema si possono porre priorit( dinamiche, variabili nel corso del tempo in modo che la possibilit( di eseguire migliori con il tempo che il processo attende nella coda dei pronti.

02 "rocessi.o!t

=er. 0.>.1 2012-0?-2>

". N !i 10

 Ing. Gabriele MONTI

www.ingmonti.it

/no scheduling con priorit( permette risposte rapide e predicibili agli eventi che riguardano i processi pi' importanti. 4 &uindi adatto ai sistemi realtime. 4o!e m ltili%ello Lo scheduling a code multiple combina le tecniche precedentemente descritte per utilizzare i vantaggi di ciascuna, sia pur con u certo aggravio dovuto alla gestione pi' complicata. I processi vengono classificati in base alle loro caratteristiche ed immessi in code diverse, all0interno delle &uali operano scheduler con algoritmi diversi. .er i processi che hanno caratteristiche realtime, come &uelli del .!. e &uelli di I5! si pu" applicare un algoritmo event driven, un round robin per i processi interattivi ed un 67) per i batch. )aturalmente per decidere &uale coda usare ogni volta ci vorr( uno "scheduler degli scheduler". .er i dettagli si veda il libro di 8ilen9ovic, al cap. :.

Interazioni fra i processi

Per * anto ogni "rocesso "ossa eseg ire in s"len!i!o isolamento ris"etto a t tti gli altri$ s"esso si im"one la necessit1 "er i "rocessi !i com nicare 'ra !i loro. Q esto acca!e sem"re 'ra i "rocessi c+e 'anno "arte !el -istema O"erati%o e! anc+e 'ra alc ni "rogrammi tente "articolarmente so'isticati$ c+e s !!i%i!ono la loro esec &ione 'ra !i%ersi "rocessi se"arati. Ogni -.O. !e%e "erci9 mettere a !is"osi&ione !ei meccanismi "er la com nica&ione 'ra i "rocessi.

Competizione e cooperazione

8 e "rocessi si !icono /in competizione/ * an!o sono in lotta "er l3accesso alla stessa risorsa. Q an!o i "rocessi sono in com"eti&ione il -.O. !e%e a""licare tecnic+e so'isticate "er allocare la risorsa. I "roblemi !o% ti all3alloca&ione !i risorse contese 'ra i "rocessi sono 'ra i "i: s"inosi !a risol%ereB * alc+e !ettaglio %err1 !ati nel ca"itolo /Programma&ione concorrente/. 8 e "rocessi in com"eti&ione "otrebbero non a%er bisogno !i com nicare 'ra !i loro$ ma solo !i tro%are il momento gi sto "er sare la risorsaB "otrebbero a%ere solo necessit1 !i / sincronizzarsi/. 8 e "rocessi si !icono /in cooperazione/ * an!o no " 9 con!i&ionare !irettamente l3a%an&amento !ell3altro. Per "oter coor!inare 'ra loro le atti%it1 !ei "rocessi coo"eranti # in!is"ensabile c+e 'ra !i essi si insta ri na com nica&ione. 8 n* e la coo"era&ione 'ra i "rocessi im"one al -.O. la "resen&a$ oltre a ' n&ioni "er la sincroni&&a&ione 'ra i "rocessi$ !i ' n&ioni "er il reci"roco scambio !i messaggi.

Thread

-i " 9 !ire c+e esistono ! e ti"i !i "rocessi$ "rocessi /"esanti/ e /leggeri/ .+ea%Cweig+t "rocess o lig+tweig+t "rocess0 I "rocessi /"esanti/ sono * elli c+e abbiamo trattato 'ino a! ora. Mssi %engono c+iamati solamente /"rocessi/. I "rocessi /leggeri/ sono meglio conosci ti come /thread/. I ! e ti"i !i /"rocessi/ si !i''eren&iano "rinci"almente nella gestione !ella memoria. Nei -istemi O"erati%i c+e gestiscono i t+rea! ./m ltit+rea!e!/0 ogni "rocesso " 9 generare n n mero arbitrario !i t+rea!$ ciasc no !ei * ali con!i%i!e lo stesso s"a&io !i memoria !el "rocesso c+e li +a generati. 8 n* e n t+rea! " 9 inter'erire s lla memoria !egli altri t+rea! e !ello stesso "rocesso /"a!re/. Il mal' n&ionamento !i n t+rea! " 9 "ro%ocare il mal' n&ionamento anc+e !el "rocesso c+e lo +a generato eIo !egli altri t+rea! !ello stesso "rocesso.

Figura 3: spazi di memoria in processi e thread !gni processo ha il suo spazio di memoria riservato per cui deve avere nel suo descrittore di processo riferimenti ad ogni parte di memoria ad esso allocata. e il sistema ha memoria virtuale, il descrittore deve anche contenere le informazioni necessarie al gestore della memoria per ritrovare, nello s;ap file, le parti della memoria del processo che sono state temporaneamente scaricate in memoria ,s;ap-

". 6 !i 10

2012-0?-2>

02 "rocessi.o!t

 Ing. Gabriele MONTI 1999 - 2006

Processi

www.ingmonti.it

ped out-. %on &ueste informazioni in grado di ripristinare il contenuto della memoria fisica &uando ne viene richiesto l0accesso. 7utte le informazioni che permettono di gestire la memoria assegnata ad un processo vengono indicate come il " contesto di memoria" ,memory context- di &uel processo. T tti i !iscorsi gi1 'atti$ e * elli ancora !a 'are$ c+e rig ar!ano i "rocessi si a""licano anc+e ai t+rea!$ cambia solo la mo!alit1 !i gestione !ella memoria. In'atti$ !ato c+e i t+rea! +anno lo stesso contesto !i memoria !el "rocesso c+e li +a generati$ il cambio 'ra ! e t+rea! !ello stesso "rocesso ./t+rea! switc+/0 # n e%ento molto meno /costoso/ !el cambio 'ra !i%ersi "rocessi ./"rocess switc+/0. 5n /t+rea! switc+/ !e%e cambiare solo i registri !ella 4P5$ mentre n /"rocess switc+/ cambia anc+e i ri'erimenti alla memoriaB !e%e "erci9 leggere !i%erse in'orma&ioni !al !escrittore !el n o%o "rocesso.

Figura 4: esecuzione di processi e thread

$elle %PU moderne! che sono al loro interno altamente parallele e sono dotate di molta memoria cache! il cam io di registri non # l&unica penalizzazione che ci si pu' attendere da un thread s(itch! perch) si rompe la "localit*"+ del programma e perci' diviene pro a ile che le pipeline si svuotino! che ci siano "cache miss" e dei "page fault" della memoria virtuale.

. Figura 5: processi figli e thread

? "er !ettagli s l "rinci"io !i localit1 si %e!a l3in!ice analitico .localit1$ "rinci"io !i0 !el =ol me1

02 "rocessi.o!t

=er. 0.>.1 2012-0?-2>

". O !i 10

 Ing. Gabriele MONTI

www.ingmonti.it

Nella ;ig ra N i !escrittori !i "rocesso !i P1 e P2 contengono sia il %alore !ei registri c+e i ri'erimenti alla memoria$ mentre i !escrittori !i t+rea! non +anno ri'erimenti alla memoria$ !ato c+e /" ntano/ im"licitamente alla memoria !el "rocesso /"a!re/. Ti"i !i contesto e !i switc+ !i contesto in n -.O. <<<< !a 'are <<<< Processi /'igli/ Ogni "rocesso !i n -.O. m ltitas,ing " 9 generare altri "rocessi. I "rocessi generati !a n altro "rocesso sono "rocessi g ali agli altri e! +anno n loro s"a&io !i memoria riser%ato. -e terminano in mo!o anomalo non coin%olgono altri "rocessi.
Esempio: Il "demone"5 internet di Linux si chiama inetd. Quando si lancia questo programma esso "diventa" un processo, che a sua volta fa partire tutti i servizi relativi ad internet che sono stati configurati su quel computer per esempio: telnet, ftpd ed eventualmente httpd, nfsd, sm!d, .." per il dettaglio sui protocolli che si veda il prossimo volume". #iascuno di quei servizi deve far eseguire almeno un processo, per cui il lancio di inetd pu$ creare diversi altri processi. Il comando %nix per visualizzare l&al!ero dei processi che sono stati generati a partire da un certo processo ' pstree: ( pstree inetd )*+ ,p inetd )*+",-,in.ftpd *+." /,in.telnetd *)0",,,login *)1",,,!ash *)2" )*+ ' un codice univoco del processo inetd, viene detto pid Process Identifier", ' di, verso ogni volta che il processo viene creato. L&opzione 3p indica di mostrare i 4I5 di tutti i processi visualizzati. Il risultato mostra che nel momento in cui pstree ' stato eseguito erano attivi, oltre al processo "padre" inetd due processi "figli" in.ftpd e in.telnetd, i demoni dei protocolli internet 674 e telnet. 8 sua volta "in.telnetd" ha un "figlio" ed un "nipote", rispetti, vamente "login" che gestisce la sessione dell&utente tramite telnet, e "!ash", l&inter, prete di comandi di quell&utente.

Gestione dei processi Descrittori di processo

4onten to !ei !escrittori !i "rocesso( PI8 8iritti "er la "er la sic re&&a Priorit1 "er l3esec &ione Processo genitore Programma eseg ito 4ontesto !el "rocesso .Program 4o nter$ -tac, Pointer$ 'lags$ registri .t tti00 -tato corrente Memoria allocata 6ltre risorse allocate .es. 'ile a"erti0 In'orma&ioni "er la contabili&&a&ione .4P5 sata$ risorse sate0

Liste dei processi

6bbiamo %isto c+e sono molte le occasioni nelle * ali n "rocesso necessita !i cambiare !i stato Ogni co!a !i "rocessi # reali&&ata "raticamente come na lista a " ntatori. I !escrittori !i "rocesso sono gli elementi !ella lista. In na lista a " ntatori ogni elemento contiene n " ntatore all3in!iri&&o !i memoria !el s ccessi%o elemento. )3 ltimo elemento contiene l3in!ica&ione c+e non seg ono altri elementi. )a lista # la str tt ra !ati "i: e''iciente "er * anto rig ar!a gli aggiornamenti$ "erc+2 i s oi elementi "ossono essere /s"ar"agliati/ nella memoria e mantenere com n* e n3organi&&a&ione se* en&iale$ anc+e se con la necessit1 !i tili&&are ogni %olta il " ntatore. In alc ni casi la lista !ei !escrittori !i "rocesso # bi!ire&ionale$ e contiene collegamenti non solo all3elemento s ccessi%o ma anc+e al "rece!ente. 4i9 "ermette algoritmi !i ricerca "i: %eloci$ anc+e se com"lica la gestione.
N 9el gergo %nix si chiama "demone" daemon" un processo non associato ad un utente od a un termi, nale. :pesso un daemon ' lanciato dal programma "init", al !oot del sistema e funziona "in !ac;, ground", dietro le quinte, senza alcuna interfaccia utente. L&effetto dell&esecuzione di un daemon ' l&aggiunta di alcuni servizi a quelli disponi!ili sul com, puter es. il daemon "inetd" permette di usare i protocolli internet 7#4<I4"".

". > !i 10

2012-0?-2>

02 "rocessi.o!t

 Ing. Gabriele MONTI 1999 - 2006

Processi

www.ingmonti.it

6lle in'orma&ioni conten te nel !escrittore !i "rocesso aggi ngiamo ! n* e n " ntatore al "rossimo elemento e!$ e%ent almente$ no al "rece!ente.

<.<.<

.rocessi in Linu=

In 5ni7 %iene creato /!al n lla/ n solo "rocesso ."rocess 00$ gli altri sono t tti /!iscen!enti/ !a * el "rocesso ./'igli/$ /ni"oti/ ..0. Il "rocesso c+e +a PI8 0 'a alc ne ini&iali&&a&ioni$ crea il "rimo "rocesso .PI8 10$ "oi si mette a /non 'ar niente/ in n loo" a % oto .!i%enta il /"rocesso i!le/0. Ogni %olta c+e lo sc+e! ler non +a ness n "rocesso !a 'ar eseg ire$ !1 il controllo al "rocesso i!le. Il "rocesso 1 'a anc+3esso alc ne ini&iali&&a&ioni$ "oi lancia il "rogramma init$ c+e 'a "artire il -.O. e t tti i !emoni c+e !e%ono "artire ini&ialmente e c+e sono scritti nel 'ile IetcIinittab. )a genera&ione !i n n o%o "rocesso !a "arte !el s o /genitore/ ./"arent "rocess/0 %iene !etta /s"awning/. Per generare n "rocesso in 5ni7 c3# la c+iamata !i sistema / fork/$ c+e genera n n o%o "rocesso ! "lican!o t tte le "ro"riet1 !el "rocesso genitore$ incl si il co!ice e! i 'ile a"erti. Il "rocesso generato # "erci9 na sorta !i clone !el genitore. 6ll3 scita !ella 'or, esiste n n o%o "rocesso$ "ronto a! eseg ire * an!o lo sc+e! ler %orr1. I ! e "rocessi genitore e 'iglio sono / g ali/ ma in!i"en!enti$ ! e istan&e !ello stesso "rogramma$ riconoscibili 'ra loro solo "er n !i%erso PI8. 8 n* e i "rogrammi "i: sem"lici !e%ono contenere il co!ice sia !el "rocesso "a!re$ sia * ello !i t tti i 'igli. Il "rocesso " 9 !eci!ere se eseg ire il co!ice !el "a!re o * ello !i no !ei 'igli g ar!an!o il %alore !i ritorno "assato !alla 'or,. -e si % ole c+e i ! e "rocessi "a!re e 'iglio non %engano ! "licati com"letamente$ alc ne risorse "ossono essere con!i%ise .".es. 'ile e memoria %irt ale0. -e in%ece si % ole c+e i ! e "rocessi abbiano co!ice !i%erso si " 9 sare la c+iamata a sistema / exec/ c+e "ermette al "rocesso !i sostit ire i ri'erimenti al co!ice !el "a!re con * ello in!icato come argomento alla ' n&ione. In * esto mo!o i "rocessi "a!re e 'iglio !i%engono !i%ersi anc+e nel co!ice. e7ec cambia il co!ice !el "rocesso e "oi lo eseg e. Per sos"en!ersi 'ino a c+e il "rocesso 'iglio non +a concl so la s a esec &ione il "rocesso "a!re sa / wait/. Per concl !ere n "rocesso si sa /exit/. Per scambiare messaggi 'ra "rocessi e "er sincroni&&arli si sa la ' n&ione / signal/$ c+e$ come !ice il nome$ s"e!isce n segnale al "rocesso. Ogni "rocesso c+e rice%e n segnale # obbligato a! elaborarlo$ "ena la morte. In'atti se na signal non %iene rece"ita !a n "rocesso esso %iene terminato !al -.O. . Per elaborare na signal ci !e%3essere nel "rogramma na "arte !i co!ice c+e %iene 'atta eseg ire a tomaticamente al s o arri%o. -e la signal non # interessante "er il "rocesso esso la !e%e es"licitamente ignorare. 6lc ne signal sono generate !al sistema in caso !i errore( - errore !i segmenta&ione( accesso alla memoria al !i ' ori !ello s"a&io !3in!iri&&i !el "rocesso - tentati%o !i eseg ire n3istr &ione !i macc+ina "ri%ilegiata Ogni "rocesso c+e termina !e%e s"e!isce al "rocesso "a!re n segnale 6ltre c+iamate !i sistema c+e 'anno ri'erimento ai "rocessi( nice( cambia la "riorit1 !el "rocesso$ la " 9 eseg ire solo il s "er ser .root0 /pause/$ /alarm/( in combina&ione con signal "ermettono !i sos"en!ere n "rocesso "er n !eterminato tem"o. 4onte7t switc+ in 5ni7 6%%iene * an!o( - gi nge na ric+iesta !3interr &ione - il "rocesso c+e eseg e 'a na c+iamata !i sistema =iene sal%ato lo stato !el "rocesso corrente$ cio# il conten to !i t tti i registri$ incl so il "rogram co nter$ nel !escrittore !i "rocesso.
L&architettura di alcune %PU prevede la presenza di diversi set di registri duplicati in modo! che per passare da un processo al ,.-. asti cam iare il set utilizzato! il contesto di un processo interrotto rimane intatto in uno dei set di registri! mentre il ,.-. usa gli altri. In "uesto modo il cam io di contesto fra processo e ,.-.! e viceversa! richiede solo di cam iare il set di registri che si usa! senza accedere alla memoria.

Il nome !el !escrittore !i "rocesso nel ,ernel !i )in 7 # tas,Pstr ct. Il %ettore /tas,/ contiene i " ntatori a ciasc no !ei !escrittori !i t tti i "rocessi c+e esistono in n istante. Il !escrittore !i "rocesso +a molte !ecine !i cam"i$ molti !ei * ali sono " ntatori .%e!i in 6""en!ice 62 la str tt ra tas,Pstr ct0.

02 "rocessi.o!t

=er. 0.>.1 2012-0?-2>

". 9 !i 10

 Ing. Gabriele MONTI Inoltre esiste na lista bi!ire&ionale c+e collega t tti i "rocessi esistenti.

www.ingmonti.it

<.<.<

7ic9less 9ernel

4ome accennato "rece!entemente$ recentemente il ,ernel )in 7 # stato mo!i'icato in mo!o !a "oter e''ett are lo sc+e! ling "reem"ti%e !ei "rocessi anc+e in assen&a !i na interr &ione regolare !a "arte !el real time cloc,. In'atti$ a "artire !alla %ersione 2.6.21 !el ,ernel )in 7$ # "ossibile com"ilarlo con l3o"&ione /tic,less/$ c+e reali&&a * esto mo!o !i ' n&ionamento. Il ,ernel tic,less tiene traccia !el tem"o in mo!o !i%erso. In%ece !i essere interrotto 1000 %olte al secon!o !all3interr "t +ar!ware !el real time cloc, ./tic,/0$ il ,ernel ri"rogramma a! ogni /tic,/ l3interr "t +ar!ware !el realtime cloc,$ "er 'arlo interrom"ere in n momento nel ' t ro in c i ci si as"etta c+e n "rocesso a%r1 bisogno !i ottenere la 4P5. 8 n* e il ,ernel /"re%e!e/ * an!o ci sar1 bisogno !i na "reem"tion e 'a in mo!o c+e l3+ar!ware interrom"a in "rossimit1 !i * el momento. In * esto mo!o si "ossono ottenere molte meno interr &ioni e la 4P5$ se il sistema non # "articolarmente im"egnato$ " 9 rimanere nello stato !i ris"armio energetico "er tem"i molto "i: l ng+i !i 1 ms. Mis ra&ioni +anno mostrato n ris"armio energetico !al 1N al 2NQ.
Questo risparmio ancora pi evidente nei sistemi virtualizzati, nei quali sullo stesso computer girano molti "computer virtuali", con il loro software. Se p.es. In un computer girano 50 macc ine virtuali, con l!approccio "classico" ci saranno 50000 interrupt al sevondo c e, se le varie macc ine virtuali sono scaric e, non servono a niente.

". 10 !i 10

2012-0?-2>

02 "rocessi.o!t