Sistemi operativi

Sistemi operativi

Introduzione ai SO

Introduzione ai sistemi operativi

Tra le varie risorse di un computer troviamo: bus, memoria, CPU, registri, memoria cache. Un sistema può essere:

• Monoprocessore, quindi dotato di una sola CPU
• Multiprocessore, costituito da tante CPU che lavorano in parallelo, ciascuna delle quali usa una memoria condivisa, propri registri e proprie memorie cache

In particolare, nei sistemi di tipo multiprocessore, troviamo tante CPU separate che usano il bus di comunicazione comune al fine di scambiarsi dati tra un’entità e l’altra. Tale processo risulta essere quindi lento perché queste entità sono esterne, indipendenti. Ogni processo può essere a sua volta, ancora più complesso: parliamo infatti di sistemi multicore. Ogni CPU è costituita internamente da tante CPU, core, indipendenti; ogni core utilizza i propri registri e le proprie cache. I core, che difatti sono delle CPU, si trovano dentro lo stesso chip e quindi la comunicazione tra loro risulta essere avvantaggiata e quindi più veloce.

Sistema operativo

Un sistema operativo è un insieme di programmi (software) che gestisce gli elementi fisici di un calcolatore (hardware); fornisce una piattaforma ai programmi applicativi e agisce da intermediario fra l'utente e la struttura fisica del calcolatore.

Qual è lo scopo di un sistema operativo?

• Permettere l’uso dell’hardware per eseguire comandi e programmi utente.
• Rendere il sistema di elaborazione facile da utilizzare (interfacce user-friendly)
• Svolgere il ruolo di “assegnatore delle risorse” ai diversi programmi utenti in esecuzione: in casi di esecuzione di diversi programmi, questi dovranno scrivere su disco. Il file è una memoria condivisa, quindi se due programmi cercano di scrivere contemporaneamente allora si crea un conflitto. Tale conflitto viene risolto dal sistema operativo che decide l’ordine dei vari processi tramite scheduling. Quindi a fronte di richieste di utilizzo (spesso in conflitto) deve decidere come assegnare le risorse hardware ai programmi utente.
• Usare l’hardware in maniera efficiente

Componenti di un SO

• User: persone o altri computer
• Sistema e programmi applicativi: programmi che mette a disposizione il server o il nostro computer. Tali programmi possono essere:
  • a corredo del s.o. (Compilatori, editor)
  • utente (giochi, Office automation)

Il vero sistema operativo si trova tra questi programmi citati e l’hardware. Operating system: Insieme di programmi di base che permette di gestire le risorse della macchina, tra cui Kernel e Shell. Tutti i programmi utente confluiscono nel Kernel e quest’ultimo, che è l’unico responsabile, controlla l’hardware: ciò significa che qualunque utente non può usare direttamente l’hardware perché la gestione delle risorse avviene attraverso il Kernel. Il Kernel è dunque l’unico che può gestire l’hardware attraverso i comandi dati dai programmi. I comandi dati arrivano al Kernel tramite la Shell: questa è un’interfaccia che visualizza i comandi, li comprende e li passa al Kernel che dovrà eseguirli.

Hardware: Fornisce le risorse di elaborazione (CPU, memoria, periferiche per I/O). Quindi, la parte fondamentale di un sistema operativo è costituita da Shell e Kernel, ovvero, rispettivamente, interfaccia verso l’utente e programmi base che gestiscono le risorse.

Le tipiche funzioni di un SO sono:

• Interprete dei comandi
• Gestione dei processi
• Gestione della memoria principale
• Gestione dei file system
• Gestione dei dispositivi I/O
• Implementazione dei meccanismi di protezione

Interprete dei comandi

L’utente e il SO comunicano attraverso la Shell, l’interfaccia che legge i comandi utente e li esegue. I comandi vengono inseriti dall’utente oppure letti da un file “script” che contiene sequenze di istruzioni che devono essere eseguite sequenzialmente. In Linux esistono diverse Shell, Windows, invece, ne possiede solo una.

Gestione dei processi

Un processo (unità attiva) è un programma (unità passiva) in esecuzione. Dato un solo programma possono esistere diversi processi relativi a quello stesso, la cui esecuzione può avvenire contemporaneamente in base all’architettura del sistema operativo (quindi, al numero di core). Un processo è in genere formato da un unico thread (unica sequenza di codice) ma possono esistere processi multithread, in grado di svolgere più compiti. Un programma monothread viene eseguito venendo assegnato dal SO alla CPU libera, la quale esegue diverse istruzioni sequenzialmente. Nel caso dei multithread, il SO cerca di trovare tante risorse (core o CPU, dipende) quanti sono i thread da eseguire, ovvero assegna ad ogni core, per esempio, un thread, così che il programma venga eseguito contemporaneamente e in maniera indipendente (cioè in modalità concorrente). Il vantaggio dei multithread è costituito dal fatto che il tempo di esecuzione si abbassa notevolmente. Tuttavia, presentano anche delle problematiche:

• I processi infatti richiedono meccanismi di sincronizzazione: se ho un file e due programmi, uno relativo alla scrittura e l’altro alla lettura dello stesso, ognuno dei due processi dovrà capire se il file è occupato. Questo problema viene risolto con i semafori e/o mutex, variabili che offre il Kernel per capire se una risorsa è libera o occupata.
• I processi possono aver bisogno di comunicare tra loro per scambiarsi dati: la comunicazione tra processi può essere tra processi sulla stessa macchina o tra processi su macchine diverse e questa avviene grazie al SO della macchina che permette di scambiare informazioni.

Il SO, in particolare il Kernel, deve:

• Decidere quali processi/thread fare eseguire sulle CPU/Core disponibili, quindi, in sostanza, si occupa delle schedulazione dei processi.
• Assegnare risorse al processo/thread.
• Terminare un processo/thread.
• Sospendere o ripristinare processi.
• Fornire meccanismi di comunicazione e sincronizzazione tra processi.

Gestione della memoria principale RAM

Quando viene eseguito un programma, e quindi, questo diventa un processo, il programma viene allocato cioè messo in memoria RAM poiché dati e istruzioni vanno contenute nella memoria principale durante l’esecuzione del processo e tale compito è affidato al Kernel. Il Kernel, quindi, deve organizzare l’uso della memoria, capire quali elementi sono utilizzati e quali invece sono liberi e deve decidere quali processi allocare e deallocare dalla memoria.

Gestione del file system

Le informazioni su memoria secondaria sono organizzate in uno o più file system, suddivisi in directory e contenenti file. Il SO gestisce tali file system: permette di creare, cancellare file, directory, cartelle, in generale di gestirli e di instaurare opportuni meccanismi di protezione di accesso, di sicurezza da attacchi interni ed esterni. Per ultimo, si occupa anche della gestione di backup.

Gestione dei dispositivi di I/O

Il SO accede ai dispositivi di I/O, cioè alle periferiche: stampanti, pen-drive, ecc. I dispositivi di I/O non possono essere gestiti direttamente dai processi utente poiché si verrebbero a creare dei conflitti sull’accesso. Esistono tantissimi dispositivi di I/O, il SO non potrebbe gestirli tutti perché dovrebbe, in tal caso, essere aggiornato continuamente. Allora, una parte di questo lavoro viene assegnata a dei piccoli programmi, driver, che servono per la comunicazione tra il SO e ciascuno dei dispositivi di I/O. Il SO manda dei comandi standard ai drivers che traducono questi comandi in comandi specifici che il dispositivo esterno è in grado di capire ed eseguire. Se cambia un dispositivo, basta cambiare il suo driver. Se il SO viene aggiornato, basta aggiornare il driver. I driver sono specifici per ogni sistema operativo e spesso per ogni versione di questo ed i produttori dei dispositivi rilasciano spesso aggiornamenti dei drivers. Quindi, il SO deve, nel caso della gestione dei dispositivi I/O:

• Offrire funzioni (comandi standard) per l’accesso ai dispositivi tramite driver;
• Gestire contese sull’utilizzo dei dispositivi di I/O da parte di più processi utente.

Meccanismi di protezione

Con il termine protezione si indica il controllo sugli accessi da parte di utenti e relativi processi alle risorse di sistema. Il SO deve:

• Permettere la definizione dei controlli che si vogliono instaurare
• Eseguire i controlli degli accessi, distinguendo tra l’utilizzo autorizzato e non
• Mantenere traccia di quali utenti usano le risorse del sistema tramite lo storico delle operazioni

Modalità di funzionamento di un SO

Dal punto di vista della gestione dei dati un SO può operare in modo:

• Batch
• Interattivo

Un programma ha delle variabili (dati) di ingresso, le elabora e produce un risultato in uscita. Nei sistemi batch si caricano diversi programmi contemporaneamente e si precaricano anche i dati che servono ai programmi. Il SO riceve così insieme programmi e dati. A seguito dell’elaborazione di ogni programma (run) otteniamo i risultati di ogni programma. Se c’è stato un errore nella programmazione ce ne si accorgerà soltanto alla fine dell’elaborazione. Questa modalità viene utilizzata nei programmi complessi di calcolo che hanno durata elevata. Nei sistemi interattivi, viene richiesto l’inserimento dei valori uno alla volta di conseguenza non appena c’è un errore questo viene subito visto. Linux permette entrambe le modalità di funzionamento.

Dal punto di vista della gestione dei programmi, le modalità di funzionamento del SO sono:

• Uniprogrammazione
• Multiprogrammazione

I SO multi-programmati permettono di allocare in memoria diversi programmi contemporaneamente e se la CPU è libera, questi vengono eseguiti diventando processi. Il vantaggio della multiprogrammazione risulta essere che, conservando tutti questi programmi in memoria, non appena si libera una CPU, questi possano essere eseguiti. Il singolo programma in memoria non è in grado di tenere la CPU occupata al 100% quindi il SO commuta tra un processo e l’altro fino a quando non vengono completati (multitasking). Nei sistemi multiprogrammati è necessario scegliere quale processo (tra quelli in memoria) si deve eseguire: tale compito, detto schedulazione della CPU, viene affidato al Kernel.

System call ed API

Il SO è inerte, fermo ed attende il verificarsi di:

• Interruzioni, interrupts, da parte di dispositivi esterni;
• Eccezioni, trap o exceptions, da parte di un programma;

Ad ogni interruzione/eccezione esistono segmenti di codice di SO per reagire opportunamente. I programmi richiedono l’utilizzo delle risorse di computer, tuttavia, i programmi utente difatti non possono gestire alcuna risorsa ma devono chiedere il “permesso” al SO. Il comando del programma utente che desidera utilizzare delle risorse hardware viene tradotto in una richiesta al Kernel e tale richiesta è detta System Call. Ogni programma allora si interrompe continuamente, fa una system call al SO e in base a ciò che necessita e per ciascuna System call il Kernel e reagire ed eseguire l’azione corrispondente. Il programma in esecuzione (processo) si interrompe perché c’è una System call, si ha un’eccezione e il Kernel risponde ed esegue la system call. Quando finisce l’esecuzione della system call, ritorna il risultato al programma e questo riprende. La CPU è il processore che esegue, allora, questa o esegue il programma o esegue la system call (paragonabile ad un programmino). Dal punto di vista della CPU entrambe le cose sono istruzioni, quindi, da parte sua, non sono distinguibili processo utente e system call.

Esistono operazioni che un comune processo non può eseguire. Ad esempio, il tentativo di scrittura da parte di un processo in zone di memoria a disposizione di altri programmi o del SO. È necessaria, quindi, una protezione da errori provocati da operazioni pericolose di alcuni processi e per far ciò, allora, è indispensabile che la CPU sappia se l’istruzione venga eseguita per conto del SO o dell’utente; in particolare:

• Per conto del SO: può fare quello che vuole;
• Per conto dell’utente: ha delle restrizioni;

Modalità di operazione di un SO

Ogni sistema opera continuamente in due diverse modalità:

• Modalità utente, quando si eseguono programmi dell’utente;
• Modalità di sistema, o modalità Kernel, quando si esegue il codice del SO;

Per far ciò la CPU dispone di un particolare bit, detto bit di modalità:

• Settato a 0 significa modalità Kernel;
• Settato a 1 significa modalità user;

Questo bit permette di stabilire se l’istruzione corrente viene eseguita per conto del SO o dell’utente. All’avvio il bit è settato in modalità Kernel, quindi 0. Quando il SO esegue un programma utente la modalità viene messa a 1 ma, quando avviene un’eccezione, il controllo passa alla procedura di gestione dell’interruzione e il bit viene messo in modo Kernel 0. Quando il Kernel finisce di eseguire la system call, il bit viene rimesso a 1 e il programma utente riprende la normale esecuzione. In questo modo la CPU può distinguere un accesso consentito da uno proibito: se c’è una richiesta di accesso di risorsa e la CPU controllando tale bit vede che è settato a 1 allora chiude il programma, cioè chiede al Kernel di bloccare tutto e chiudere i processi in esecuzione. Il SO termina in modo anomalo il programma e si genera un messaggio di errore, si libera memoria e si crea una memory dump. Il numero di modalità può essere maggiore di 2, dipende dall’HW.

API

Qualunque sistema operativo offre delle System call che l’utente può utilizzare ma in realtà queste chiamate di sistema non sono direttamente utilizzabili dal programmatore ma sono contenute in certe librerie, dette API, Application Program Interface, cioè interfaccia per la programmazione di applicazioni. Ogni SO ha le proprie funzioni delle System Call racchiuse nelle API. Le chiamate di sistema native non vengono mai direttamente usate ma vengono usate delle funzioni che le contengono: le API sono librerie che contengono tali funzioni in C dove ciascuna di queste funzioni al suo interno richiama le System Call. Questo perché:

• Per semplicità: Per usare le system call originarie bisogna essere programmatori esperti a causa della loro complessità. Le API rappresentano un modo facilitato di utilizzare queste funzioni.
• Per portabilità: Supponiamo che un computer possieda una certa versione di un determinato SO. Il SO offre una system call A. Se viene aggiornata la versione del SO, la system call A viene eliminata e sostituita dalla system call B (identica, ma con nome diverso). Ciò comporta il fatto che ogni volta che si cambia versione del SO il programma dovrebbe essere cambiato. Invece, utilizzando le API, all’interno del programma viene usata la funzione API che al suo interno richiama la system call A. Quando si aggiorna il SO, la system call A viene eliminata e sostituita da B ma aggiornando il SO anche l’API cambia (rimanendo con lo stesso nome) e al suo interno richiamerà la system call B. Il programma rimane valido su qualunque SO che espone la stessa API e il programma non cambia se le system call cambiano.

Abbiamo detto finora che:

• Gli utenti lavorano in modalità utente;
• Ogni System Call causa il passaggio in modalità Kernel;

Ma questo concetto come si applica visto che il processo utente usa l’API? Vediamo, nello specifico, cosa succede quando un processo Utente chiama un’API. Tutti i SO hanno un programma sempre in esecuzione, detto Interfaccia alla chiamata di sistema che intercetta le chiamate a funzioni API e invoca le relative System Call. Viene offerta dal sistema di run-time support system delle librerie. Ogni volta che il processo utente chiama un’API, l’interfaccia alla chiamata di sistema si accorge della chiamata a funzione API, la comprende e chiama la System call che è all’interno dell’API. L’esecuzione della System call viene provocata dall’interfaccia alla chiamata di sistema: questa stessa poi, ritorna un valore. In Linux, la system call interface è dentro la libreria glibc.

Ad esempio, un programma che invoca una funzione in C che a sua volta richiama una funzione API: quando viene eseguito questo programma, l’interfaccia capisce che c’è questa API e chiama la system call relativa. Quando termina la system call ritorna al programma il risultato.

Per passare parametri al SO, si possono utilizzare metodi diversi: In Linux, si utilizzano gli indirizzi. I parametri si memorizzano in un blocco di memoria e si passa l’indirizzo relativo al blocco, che il sistema operativo legge.

Categorie di API