Înainte Înapoi Cuprins

9. Cum ține computerul meu procesele să nu se calce unul pe altul?

Programatorul kernelului are grijă să împartă procesele în timp. Sistemul dvs. de operare trebuie deasemenea să le dividă în spațiu, astfel încât procesele să nu calce unul pe memoria de lucru a altuia. Chiar dacă presupuneți că toate programele încearcă să fie cooperative, nu doriți ca un bug (defect de programare) în unul din ele să fie capabil de a le strica pe celelalte. Lucrurile pe care sistemul de operare le face pentru a rezolva aceasta sunt numite management de memorie.

Fiecare proces în grădina dvs. zoologică are nevoie de zona proprie de memorie core, ca loc din care să-și ruleze codul și în care să țină variabile și rezultate. Puteți să vă gândiți la acest set ca fiind compus dintr-un segment de cod read-only (numai citibil) (conținând instrucțiunile procesului) și un segment de date care poate fi scris (conținând depozitul de variabile al tuturor proceselor). Segmentul de date este cu adevărat unic pentru fiecare proces, dar dacă două procese rulează același cod Unix aranjează automat pentru ele să împartă un singur cod de segment ca măsură de eficiență.

Eficiența este importantă, deoarece memoria core este scumpă. Câteodată nu aveți îndeajuns încât să țină mulțimea întreagă de programe pe care mașina le rulează, mai ales dacă folosiți un program mare precum un server X. Pentru a rezolva aceasta, Unix folosește o strategie numită memorie virtuală. Nu încearcă să țină tot codul și datele pentru un proces în core. În schimb, ține în jur numai un set de lucru relativ mic; restul stării procesului este lăsată într-o zonă specială de pe hard disc numită spațiu de swap.

Pe măsură ce procesele rulează, Unix încearcă să anticipeze cum se va schimba setul de lucru și să aibă numai bucățile care sunt necesare în core. Realizând aceasta efectiv este în același timp complicat și păcălitor, așa că nu o să încerc să o descriu complet aici -- dar depind de faptul că referințele la date și cod tind să se întâmple în mănunchiuri, cu fiecare nouă referință foarte probabil să se refere undeva aproape de una veche. Așa că dacă Unix ține în jur codul sau datele cele mai frecvent (sau recent) folosite, de obicei o să reușiți să salvați timp.

Notați că în trecut, acel "Câteodată" de acum două paragrafe era "Aproape mereu" -- mărimea core fiind tipic mică relativ la mărimea programelor care rulau, așa că swaparea era frecventă. Memoria este cu mult mai ieftină în zilele noastre și chiar mașinile low-end (cele mai proaste) au destul de multă. Pe mașinile moderne pentru un singur utilizator cu 64MB de core și mai mult, este posibil să rulați X și o variatate de treburi tipice fără să se facă swap vreodată.

Chiar în această situație fericită, partea sistemului de operare numită manager de memorie încă mai are muncă importantă de făcut. Trebuie să se convingă că programele pot să-și altereze doar propriul segment de date -- adică, să prevină cod eronat sau rău intenționat într-un program de a strica datele din altul. Pentru a face aceasta, păstrază un tabel de segmente de date și cod. Tabelul este actualizat oricănd un proces cere mai multă memorie sau eliberează memorie (ultima de obicei când se termină).

Acest tabel este folosit pentru a da comenzi la o parte de hardware internă specializată numită MMU sau memory management unit (unitate de management memorie). Cipurile procesoarelor moderne au MMUuri contruite chiar în ele. MMUul are abilitatea specială de a pune garduri în jurul zonelor de memorie, astfel încât o referință în afara granițelor va fi refuzată și va cauza o ridicarea unei întreruperi speciale.

Dacă vedeți vreodată un mesaj Unix zicând "Segmentation fault" "core dumped" sau ceva similar, aceasta este exact ceea ce s-a întâmplat; o încercare a programului care rula de a accesa memorie în afara segmentului său a ridicat o întrerupere fatală. Aceasta indică un bug în codul programului; core dump (memoria aruncată) care o lasă este informație pentru diagnosticare intenționată de a ajuta un programator să găsească defectul.

Există un alt aspect de a proteja procesele unul de altul în afară de segregarea memoriei pe care o accesează. Doriți deasemenea să le controlați accesul la fișiere astfel încât un program cu buguri sau cod rău intenționat să nu poată strica bucăți critice ale sistemului. De aceasta Unix are permisiuni de fișiere pe care o să le discutăm mai târziu.


Înainte Înapoi Cuprins