I SISTEMI OPERATIVI (1)

Transcript

1 I SISTEMI OPERATIVI () un computer può essere pensato come una stratificazione di macchine virtuali, ciascuna delle quali mette a disposizione alcuni servizi, che sono utilizzabili mediante chiamate effettuate in un linguaggio di programmazione caratteristico del livello considerato (ad es. linguaggio macchina, C, comandi). Il sistema operativo, è la più esterna delle macchine virtuali, quella che permette all utente (o agli utenti) di utilizzare ad alto livello il computer. E anch esso stratificato a livelli e prevede: Interfaccia Utente: Testuale o Grafica (con finestre) Ambiente di programmazione: editor, compilatori, debugger, Librerie, data base, Linguaggi di sistema: L. di programmazione per applicazioni, L. di configurazione (es. makefile), L. interfaccia utente(es.shell), L. servizi di sistema (funzioni del S.O. system call ).

2 I SISTEMI OPERATIVI (2) 2 Sarà compito del s.o. gestire - risorse software quali: Archiviazione dati e programmi, database, librerie, Esecuzione di programmi, compilatori e debugger Ingresso e uscita (I/O), Comunicazioni, remote login, remote file transfer, posta elettronica - risorse hardware quali: processore, memoria, dispositivi, I moderni s.o. prevedono la multiprogrammazione: più processi di utenti diversi vengono eseguiti contemporaneamente condividendo le risorse quali CPU, memoria, periferiche. Il s.o. effettua l'allocazione delle risorse agli utenti, ottimizzandone la gestione tramite opportune politiche e risolvendo i conflitti di accesso tramite sincronizzazione e mutua esclusione. Per tali scopi tutti i s.o. prevedono alcuni moduli fondamentali: Scheduler, Gestore della Memoria, Gestore dell I/O.

3 I PROCESSI E LA LORO GESTIONE 3 La gestione dei processi, la loro creazione e terminazione e la gestione delle comunicazioni fra processi e' la parte piu' importante (il nucleo) di un Sistema Operativo. Definizione di Processo: e' un'attivita' sequenziale, controllata da un programma, che si svolge su un processore, in un proprio ambiente costituito dal contenuto dei registri del processore e dallo stack. Nel caso di sistemi multiprocessore, il processo puo' non essere legato ad un particolare processore. In un sistema Multiprogrammazione piu' processi condividono (in interleaving) la stessa CPU, quindi ciascun processo non avanza in modo continuo, pero' quando avanza, occupa in modo esclusivo un processore.

4 I PROCESSI 4 Un processo e' rappresentabile da una terna P = (IM, IP, S) dove: IM Immagine in Memoria: insieme del codice e dei dati, modificabile dal processo in avanzamento. Puo' essere interamente contenuta in memoria, in modo statico, o essere presente solo parzialmente (gestione dinamica). IP Immagine del Processore: Informazioni sul processo mantenute nei registri del processore, anch'esse modificabili. S Stato di avanzamento: un processo si trova in un certo stato tra tre stati possibili: Ready, Running e Blocked Stato Running: il processore e' assegnato al processo (dal S.O.) che puo' avanzare dell'esecuzione. Stato Blocked: il processo non dispone del processore perche' bloccato in attesa di un servizio (es. attesa I/O). Stato Ready: il processo e' in attesa dell'assegnazione del processore, che e' occupato da un altro processo. Un processo puo' essere bloccato o mandato in esecuzione a seconda della disponibilita' del processore e della politica di assegnazione della CPU ai processi. I processi in stato ready (pronti) sono selezionati per l'esecuzione in base ad una opportuna politica (schedulazione). Gli obiettivi sono diversi: ) evitare che la CPU sia inattiva, 2) fare avanzare i processi con velocita' dipendenti dalla loro priorita', 3) evitare che un processo debba attendere per un tempo indefinitamente lungo prima di essere eseguito (attesa indefinita o starvation).

5 I PROCESSI IN UNIX 5 Fase di Compilazione programma eseguibile program text data compilatore Fase di Caricamento: viene caricato il codice in memoria con la exec text regioni data stack Fase di Esecuzione: esecuzione user mode user stack system call kernel mode kernel stack

6 ARCHITETTURA UNIX 6 L architettura dei s.o. UNIX, è composta di 3 livelli, hardware, kernel e utente. Il kernel schedula i processi, gestisce le comunicazione tra i i processi, alloca e dealloca memoria, gestisce il file system e le periferiche. In particolare il kernel mette a disposizione dell utente delle funzioni (system call) contenute in librerie di sistema, per eseguire I/O, leggere scrivere file, creare e eliminare processi, modificarne le priorità, ecc. Le system call possono essere chiamate all'interno di un programma, esattamente come normali funzioni implementate dall utente. La loro esecuzione tuttavia e' diversa dall'esecuzione di una funzione normale in quanto vengono eseguite in modo kernel.

7 SYSTEM CALL In Unix non esistono processi del kernel e processi utente separati ma solo processi che passano da modo kernel a utente e viceversa. Infatti Unix e' un S.O. con modello a chiamata di procedura. Una procedura eseguita da un processo può non appartenere al pro_ cesso che la sta eseguendo, potrebbe ad esempio essere una procedura di schedulazione per scegliere il successivo processo da attivare, o una routine di interruzione a seguito di un segnale esterno. Tali procedure del kernel sono eseguite in modo kernel. Quando un processo opera in modo kernel utilizza uno stack del kernel (all'interno dell'area utente) separato dallo stack utente. Il codice del kernel e le sue strutture dati sono condivise da tutti i processi, e non fanno parte di un processo particolare. Le system call che modificano le tabelle e i dati del kernel devono essere eseguite in mutua esclusione. Il sistema utilizzato da Unix e' quello di impedire l'interruzione di tali routine a causa di interrupt (anche da parte del clock) o rischedulazione. Le procedure eseguite in modo non interrompibile devono quindi essere brevissime. Un processo quindi puo' essere: in esecuzione in modo utente, In esecuzione in modo kernel, in stato ready, in stato waiting, detto anche sleeping. 7

8 File System Unix 8 Dal Punto di Vista dell Utente: eseguibili File regolari: testo.. Directory: Per organizzare il file system file speciali: device fisici (tty, disks, printers) Pipe: (per la comunicazione fra processi) Dal Punto di Vista del Sistema Operativo: i-nodes + dati - Gli i-node (Index NODE) sono la rappresentazione interna dei file unix, - risiedono su disco, possono essere copiati in memoria, - esiste un i-node per ogni file fisico, - possono esistere più file, detti link, (anche con nomi diversi) che rappresentano lo stesso file fisico (i-node) pippo link pluto file i-node..

9 Informazioni negli i-node 9 Un i-node su disco contiene: Proprietario del file tipo di file diritti di accesso data di accesso numero di link al file (link counter) indirizzi dei blocchi che contengono il file dimensioni del file Un i-node in memoria contiene: indice di quell inode su disco file system di appartenenza numero di istanze attive del file (es. compilatore) STATO DELL I-NODE: locked? c é un processo in attesa? l i-node in memoria é stato modificato?

10 Struttura dei file Regolari 0 Ogni blocco del disco é identificato da un numero Ogni i-node contiene un elenco dei blocchi che memorizzano il file Unix adotta l allocazione gerarchica indicizzata dei blocchi del file data blocks direct 0 direct direct 9 single indirect double indir. triple indirect 256 indirizzi 024 B 024 B 024 B 024 B 024 B 024 B 024 B (KB x 0)+(KB x 256)+(KB x )+(KB x )=6GB

11 Strutture Dati per Gestire i File Aperti User file table (per il singolo processo): lista dei file aperti per processo (nell area utente) di solito ha 20 entry (max 20 file aperti contemp.) le entry puntano alla File table (globale) ogni entry è indicizzata da un file descriptor restituito dalla system call open() al momento dell apertura del file fd=open(nomefile, mode); File table (globale, per tutti i processi) : lista globale dei file aperti Lista degli i-node in memoria sempre in memoria centrale ogni entry punta ad un i-node in memoria ogni entry contiene l offset della prossima read/write user file table file table count read.... count rd-wrt. count write i-node list count /etc/passwd count myfile.

12 System call OPEN 2 fd = open( file,mode) (fd: user file descriptor) il kernel: recupera l i-node di file e controlla i permessi alloca una nuova entry nella FILE TABLE che punterá all i-node in memoria setta a zero l offset del puntatore in lettura/scrittura alloca una nuova entry nella USER FILE TABLE che punta alla entry corrispondente nella FILE TABLE il file descriptor fd ha come valore l indice della entry nella USER FILE TABLE

13 User file descriptor 0,, = Standard Input (STDIN) = Standard Output (STDOUT) 2 = Standard Error (SDTERR) stdin, stdout, stderr sono assunti di default da tutti i processi la convenzione é utile per la redirezione dell input/output e per l uso delle pipe possono essere gestiti come normali file (cioé chiusi, riassegnati, riaperti, )

14 system call CLOSE 4 close(3) close(4) user file table NULL NULL file table rilasciato.... rilasciato. count write count := count - i-node table count /etc/passwd.... i-node ritorna in free list.

15 Altri tipi di file Unix: PIPE file di contenuto transitorio i dati possono essere letti solo nell ordine in cui sono stati scritti (FIFO) dimensione massima: 0 blocchi (i 0 blocchi ad indirizzamento diretto dell inode) servono per le comunicazioni veloci tra processi distinguiamo Unnamed pipe e Named pipe Unnamed Pipe risiedono solo in memoria vengono riferite solo mediante file descriptor Vengono implementate come file normali usando un i-node. Solo i blocchi indirizzati direttamente vengono usati per lettura/scrittura, e sono gestiti in modo circolare. ad ogni pipe sono associati un file descriptor in lettura ed uno in scrittura solo processi padre/figlio possono usare una unnamed pipe sono automaticamente rimosse alla morte dei processi Named Pipe esistono nel file system qualsiasi processo puó usarne una (se ha i permessi) 5

16 Unnamed PIPE 6 pipe(fds) int fds[2] fds[0] = lettura fds[] = scrittura read pointer write pointer offset 0 offset blocchi diretti dell i-node i dati vengono letti nell ordine in cui sono stati scritti (no lseek) i dati possono essere letti una sola volta (vengono consumati ) un dato non puó essere sovrascritto prima che sia stato letto (il processo scrittore é messo in wait) la lettura di una pipe vuota provoca la sospensione del processo lettore

17 esempio di uso di Unnamed pipe 7 char string[] = hello main() { char buf[024]; char *cp, *cp2; int fds[2]; pid_t pid; pipe(fds); pid=fork(); // creo un nuovo processo // si crea una nuova user file table per il figlio if(pid==0) { // sono il processo figlio close(fds[0]); for (;;) write(fds[], string, 6); //scrivo verso il padre } else { // sono il processo padre close(fds[]); for (;;) read (fds[0], buf, 6): // ricevo dal padre tramite pipe } Il processo figlio scrive (produce dati) sulla pipe all infinito. Il processo padre legge (consuma) dalla pipe, per sempre, attendendo ogni volta che il figlio abbia prodotto un dato.

18 named pipes 8 mknod(file_name, PIPE, 0); crea il file file_name che viene gestito come una pipe file_name é un file del file system, quindi ogni processo lo vede e puó usarlo, se ha i permessi. anche questa pipe é sospensiva 3

19 esempio di uso di named pipe 9 #include <fcntl.h> char string[] = hello ; main(argc,argv) int argc; char *argv[]; { int fd; char buf[256]; /* creazione di una named pipe con permessi di lettura/scrittura per tutti gli utenti */ mknod( fifo, 00777,0); if (argc == 2 ) fd = open( fifo, O_WRONLY); else fd = open( fifo, O_RDONLY); for(;;) if (argc == 2) write(fd, string, 6); else read(fd, string, 6); } 4