Parte 1: Introduzione, Struttura dei sistemi di calcolo, Strutture del sistema operativo

1. Introduzione

• Architettura dei sistemi di calcolo

2

1. Introduzione

• Un Sistema Operativo (SO) è un intermediario fra l’hardware (hw) e gli utilizzatori di tale hw

• Utilizzatore è definito come (=:=) programmi che risolvono problemi per (classi di) utenti umani

• Scopo primario è offrire un ambiente in cui eseguire programmi

3

1. Introduzione

• Diversi punti di vista:

– Governo; fornisce un ambiente

– Allocatore e Gestore di Risorse: hw software (sw)

• tempo di CPU, memoria primaria e secondaria, • dispositivi di I/O

– Programma di controllo degli utenti rispetto all'I/O

• 2 obiettivi primari:

– Rendere il sistema conveniente da usare – Usare il sistema in modo efficiente

1. Introduzione

• Confine del SO non ben definibile: fino ad includere window system!

• Vediamo l’evoluzione per:

– terminologia – concetti fondamentali

5

1.2 Sistemi Primitivi

• Macchine hw enormi, usabili (difficilmente) solo dal programmatore, direttamente dalla

console del sistema

• 1° Passo: Sviluppo di librerie di uso comune specie per I/O

– device driver (driver di dispositivo): rendere indipendente l’I/O dai dispositivi del sistema – driver di dispositivo conosce come funziona il

dispositivo e si interfaccia in modo standard con il resto del sistema

6

1.2 Sistemi Primitivi

• Compaiono i compilatori (Fortran, Cobol)

– più facile programmazione

– più difficile preparare il programma per l’esecuzione (varie fasi: compilazione, linking, caricamento, esecuzione)

– grandissimo tempo di approntamento per l’esecuzione di un programma

1.3 Semplici Sistemi Batch

• Scopo: aumentare l’utilizzazione della macchina

• 2° Passo: Monitor residente

– Figura professionale dell’operatore di macchina – il programmatore resta fuori della sala

macchina!

– Lavori simili messi nello stesso lotto (batch)

• {meno tempo di approntamento: e.g. prima tutte le compilazioni, poi i link, poi eseguire i programmi generati,…}

8

1.3 Semplici Sistemi Batch

• Monitor residente contiene

– sequenzializzazione automatica dei job – interprete del linguaggio di comandi (JCL) – Caricatore

– Set di device driver

• Mancanza di interazione fra utente (programmatore) e job

• Buon turn-around time (=:=)

– tempo_restituzione_job - tempo_sottomissione_job

9

1.3.2 Sovrapposizione di CPU e I/O

• Mentre un device fa I/O la CPU è in un ciclo attesa ⇒ bassa utilizzazione • Elaborazione off-line (fuori linea)

– I/O su nastro – Utilizzo di calcolatori ausiliari, operazioni manuali – Ritardo nel riempimento dei nastri

1.3.2 Sovrapposizione di CPU e I/O

(Cont)

• Spooling (Simultaneous Peripheral Operation On-Line)

– Reso disponibile dai dischi (accesso diretto!) – Esecuzione contemporanea dei diversi flussi di

I/O

11

1.3.2 Sovrapposizione di CPU e I/O

(Cont)

• lanciati dalla CPU

– esecuzioni dei job sovrapposta all’I/O – maggiore utilizzazione

– Utile anche per elaborazioni da remoto

• Job Pool =:= gruppo di job pronti per l’esecuzione

– È possibile scegliere l’ordine di esecuzione – Job Scheduling (=:= scelta dell’ordine)

12

1.4 Sistemi Batch Multiprogrammati

• Un singolo utente usa la CPU oppure usa l’I/O, perché è un programma sequenziale • Multiprogrammazione =:= Caricare in

memoria primaria per l’esecuzione numerosi job

– Quando un job richiede I/O, passare ad eseguire un altro job che richieda invece CPU

1.4 Sistemi Batch Multiprogrammati

• Il SO deve prendere decisioni al posto degli utenti

– Quale job in memoria eseguire fra quelli che richiedono la CPU? =:= CPU scheduling – Protezione ⇒ i job non si devono "disturbare"

né "spiare"

14

1.5 Sistemi Time-Sharing

• Estensione della multiprogrammazione (inizio anni ‘60).

• Obiettivi:

– Gli utenti sono in grado di interagire con il programma in esecuzione

– programmi interattivi

– interpreti di comandi interattivo (un comando dietro l’altro)

– debugger interattivo per facilitare la messa a punto dei programmi

15

1.5 Sistemi Time-Sharing

• File System in linea per tenere dati e programmi

– File =:= collezioni di dati correlati fra loro, definita dal creatore del file

– Directory =:= raggruppamenti logici di file

• Nuovi "tipi" di utenti possono usare con profitto la macchina e i suoi programmi

1.6 Sistemi di Calcolo Personali (PC)

• Calcolatore dedicato ad un singolo utente

– Diminuzione del costo della CPU e dei dischi

• IBM PC + MS-DOS+Windows • Apple Macintosh+MacOS

• Iniziale regressione culturale riguardo ai SO:

– single user – monoprogrammazione – niente protezione – virus – worms 17

1.6 Sistemi di Calcolo Personali (PC)

• Ora si torna faticosamente alla civiltà perché:

– hw migliore (workstation) – reti di calcolatori (LAN) – sistemi distribuiti

– uso dei PC nei gruppi di lavoro

• Evoluzione dei sistemi di calcolo e dei SO

1.7 Sistemi Paralleli

• Multiprocessori =:= più di una CPU, e in comune:

– bus di sistema, clock, memoria (spesso) periferiche – accoppiamento stretto

• Aumento del throughput (=:= job completati all’ora) a parità di costo perché

– costi I/O e struttura condivisi – miglior costo per CPU medio-piccole

20

1.7 Sistemi Paralleli

– vantaggio prestazionale cresce meno che linearmente col costo

– maggiore affidabilità: fail-soft, graceful degradation

– Simmetrici =:= ciascun processore esegue una copia del SO

– Asimmetrici =:= ogni processore ha un compito specifico

21

1.8 Sistemi Distribuiti

• Sistemi con molte CPU che non condividono memoria né clock → sistema di comunicazione • Accoppiamento lasco

• Vantaggi:

– Condivisione delle risorse

– Accelerazione del calcolo (load sharing) – Affidabilità (se i siti sono indipendenti, altrimenti il

contrario!)

– Supporto alla comunicazione e alla cooperazione fra gli utenti

1.9 Sistemi Real-Time

• =:= quando ci sono requisiti rigidi sui tempi impiegati dalle applicazioni della macchina o sul flusso dei dati

– Es. controllo di dispositivi in applicazioni industriali

• I limiti di tempo sono ben definiti e

prefissati:

– l’elaborazione deve terminare entro un certo tempo

23

1.9 Sistemi Real-Time

• Il programmatore applicativo deve fare la sua parte, e il SO la sua!

• Hard real-time =:= obbligo tassativo

– → limitata (o nulla) memoria secondaria – → ROM, FLASH-EPROM, EEPROM – → SO molto semplici per garantire tempo di

esecuzione limitato superiormente – ⇒ ⇒ SO specializzati

24

1.9 Sistemi Real-Time

• Soft real-time =:= obbligo non tassativo, compatibile con la coesistenza con task che non sono real-time

– non sono adatti al controllo industriale – applicazioni multimediali, realtà virtuale,

esplorazione sottomarina o spaziale, ... – è una funzionalità sempre più diffusa

Conclusioni

• I SO sono dei mediatori fra utenti e hw per fornire

– ambiente più conveniente per l’esecuzione dei programmi

– aumentare l’efficienza dell’utilizzo dell’hw

• Continua evoluzione sotto la pressione di

– bisogni degli utenti – caratteristiche dell’hw – costo dell’hw

– modo di usare la macchina che gli stessi SO rendono possibile

26

2 Strutture dei Sistemi di Calcolo

• Dal corso di Architetture • Architettura generale in figura

27

2.1 Operazioni della Macchina

• Bootstrap per partire

• Interrupt & Trap & System Call

• Vettore delle interruzioni & salvataggio del contesto

• Disabilitazione delle interruzioni, mascheramento

• I SO sono event-driven

– interrupt – trap

2.2 Struttura dell’I/O

• Controller per ogni dispositivo

– SCSI (Small Computer System Interface) controlla in daisy chain fino a 7 dispositivi – EIDE (Enhanced Integrated Drive Eletrocnics)

controlla fino a 4 dischi

• Ha memoria locale, CPU locale, sposta i dati dai suoi buffer al dispositivo controllato

29

2.2.1 Interrupt

• L’utente può vedere l’I/O come sincrono o

asincrono

• Sincrono =:= la system call termina quando l’I/O termina

• Asincrono =:= la system call termina quando l’I/O è avviato; un’altra system call necessaria per attendere e/o prelevare risultati

30

2.2.1 Interrupt

• Il SO può a sua volta fare I/O in modo sincrono o asincrono:

– sincrono =:= la CPU cicla in attesa della terminazione, ad es. dell’interrupt

– asincrono =:= la CPU passa a fare altro fino all’interrupt

– → maggiore efficienza ed utilizzazione della CPU!

I/O sincrono vs asincrono

• Confronto tra i due metodi

32

2.2.2 Struttura DMA

• I dispositivi veloci non possono interrompere ad ogni byte trasferito • DMA =:= Direct Memory Access: il driver

trasferisce direttamente da/in memoria i dati • Il driver inizializza il controller DMA per

un trasferimento di un blocco; il controller DMA interrompe quando tutto il

trasferimento è finito

33

2.3 Struttura della Memoria

• Corso di Architetture! (Richiami) • I programmi devono essere in memoria

principale (MP) per essere eseguiti

– dimensione della MP: da milioni di byte a migliaia di milioni di byte

• Architettura Von Neumann: fetch & execute, metodi di indirizzamento, memory-mapped I/O

2.3 Struttura della Memoria

• La MP è ancora troppo lenta per la velocità della CPU

– memoria cache fra CPU e MP, sulla CPU

• La MP è volatile, non permanente e troppo piccola per i bisogni degli utenti

– memoria secondaria (MS)

35

2.3 Struttura della Memoria

• La MS è spesso costituita da dischi magnetici a testine mobili (anno 2001)

– 7200 giri/m, molti "piatti", 2 facce, molti settori – 10-40 MB/s transfer rate, tempo di accesso 8-20 ms – capacità 10-75 GB

• Controller di disco, a volte dotato di memoria cache

• Floppy, dischi ottici, nastri magnetici

– → Gerarchia di memorie

36

2.4 Gerarchia di Memorie

• Velocità implica costo maggiore, capacità

P i ù v e l o c i P i ù c a p a c i

2.4.1 Caching

• Il luogo di immagazzinamento a lungo termine non è il più conveniente per l’uso a breve termine

– Durante l’uso copiare l’informazione in una memoria più veloce ma più costosa e più piccola – Ricopiare l’informazione in quella permanente

meno veloce, meno costosa, più grande, dopo l’uso

• La gerarchia della figura è una gerarchia di cache, una sull’altra

38

2.4.1 Caching

• Gestione della cache: quanto più è veloce, tanto più la gestione deve essere veloce e fatta in modo automatico

– registri-cache-MP: hw della CPU – MP-MS: il SO

– MS-Memoria ottica: dispositivi magneto-ottici – MS-Nastri: utente, ma ora anche il SO

39

2.4.1 Caching

• Coerenza e consistenza della cache: problema quando i dati sono presenti in più memorie e in più posti

– molte cache dello stesso dato, ad es. in un multiprocessore stretto

2.5 Protezione Hardware

• Corso di Architetture! [Richiami]

• Condivisione delle risorse → protezione da cattivo uso (incorretto e malizioso)

• Esiste condivisione anche in ambiente monoprogrammato (PC!): programmi eseguiti in successione possono distruggersi i dati su disco

– → Proteggere il SO e tutti i programmi dai programmi malfunzionanti

41

2.5.1 Operazioni in Dual-Mode

• Corso di Architetture!

• Stato normale (modo utente) e stato privilegiato (modo monitor)

– istruzioni privilegiate eseguite in modo monitor: solo il SO può effettuare queste operazioni, garantendo la protezione hw

42

2.5.2 Protezione dell’I/O

• Le istruzioni di I/O sono privilegiate (Corso di Architetture!)

• Solo il SO può accedere ai dispositivi di input/output

• I primi microprocessori non avevano istruzioni privilegiate, e quindi i SO non proteggevano l’I/O (vedi MSDOS)

2.5.3 Protezione della Memoria

• Dati del SO (ad es. interrupt vector) + codice SO

• Dati e codice dell’utente

– indirizzi legali di un programma

• Esempio di protezione: registro base + limite

– Protezione a cura dell’hw della CPU

– Registri gestiti dal SO con istruzioni privilegiate

44

45

2.5.4 Protezione della CPU

• Il SO è attivo solo quando la CPU lo esegue

(è la cosa più difficile da capire!)

– Esempio: esecuzione di una system call

• ⇒ Come riprendere la CPU ad un programma utente?

• Dispositivo Timer che genera interrupt a tempo

2.5.4 Protezione della CPU

• Il Timer è caricato con istruzioni

privilegiate, gestito tramite interrupt vector protetto

• Può anche servire a calcolare data e ora • Dispositivo Clock, che genera interrupt

periodicamente (a frequenza di rete)

47

2.6 Architettura Generale di un Sistema

• Maggiore utilizzazione della CPU

– multiprogrammazione – time-sharing

• Condivisione delle risorse

– protezione

– modifica dell’architettura del calcolatore – sistemi a due stati/modi

– trap per chiamare il SO

• Passaggio di info al SO

– esecuzione della funzione del SO

– ritorno al programma utente chiamante (prima o poi!)

48

3. Strutture di SO

– Progettazione e implementazione

50

3.1.1 Gestione dei Processi

• Processo =:= un programma in esecuzione • È l’unità di lavoro

– ♦ del SO – ♦ dell’utente

• I processi sono concorrenti (=:= eseguono contemporaneamente)

– ♦ multiplexing della CPU

51

3.1.1 Gestione dei Processi

• Il SO è responsabile delle seguenti attività:

– Creazione e cancellazione dei processi – Sospensione e ripristino dei processi

– Fornitura di meccanismi per la sincronizzazione – Fornitura di meccanismi per la comunicazione – Fornitura di meccanismi per la gestione dei

3.1.2 Gestione MP

• Numerosi programmi in memoria ⇔ contesa sulla MP

• Attività del SO per la gestione della memoria

– Tenera traccia di quali parti della memoria sono utilizzate e da chi

– Decidere quali processi caricare in memoria quando vi sia spazio

– Allocare e deallocare spazio in base alle necessità

• Interazione con la gestione della CPU: per

eseguire occorre essere in memoria!

53

3.1.3 Gestione della MS

• I programmi e i dati rimangono su disco fino al momento del caricamento

• Il SO è responsabile delle seguenti attività:

– Gestione dello spazio libero – Allocazione dello spazio – Scheduling del disco

54

3.1.4 Gestione del sistema di I/O

• Obiettivo: nascondere il più possibile le differenze fra i vari controller

• Componenti principali:

– Sistemi di buffer-cache

– Interfaccia generale per device driver – Insieme di driver specifici

3.1.5 Gestione dei file

• La parte (più) visibile di un SO • Scopo: fornire una visione uniforme e

astratta della MS

– raccolta di file

– decisi dal creatore/utente

• Organizzazione in directory: struttura logica decisa dall’utente

• Condivisione ↔ controllo degli accessi

56

3.1.6 Sistema di Protezione

• I diversi processi devono essere protetti dalle attività degli altri processi

• La protezione è un meccanismo che controlla l’accesso da parte di programmi, utenti o processi alle risorse di un sistema • La protezione aumenta l’affidabilità del

sistema perché può individuare errori alle interfacce fra i componenti

57

3.1.7 Reti

• Può fornire accesso generalizzato ad una rete di comunicazione

• Può essere un sistema operativo distribuito, che fornisce le basi per costruire

3.1.8 Interprete di comandi

• =:= interfaccia tra utente e SO

• A volte parte del SO, altre volte uno speciale programma applicativo (shell in Unix e MsDos) • A volte orientato a comandi, a volte un vero e

proprio window & menu system

– immagini (icone) rappresentano programmi, file, directory

– si punta e selezionano icone o menu, usando il bottone del mouse (clickando) si attivano programmi, passando loro gli oggetti selezionati come argomenti

59

3.2 Servizi del SO

• Fornisce servizi ai programmi e agli utenti di tali programmi

• Rendono la programmazione della macchina più semplice e produttiva:

– esecuzione di programmi – I/O e manipolazione di file – comunicazione fra i processi – Error detection

60

3.2 Servizi del SO

• Rendono l’utilizzo della macchina più efficiente

– allocazione delle risorse

– contabilizzazione dell’uso delle risorse – protezione e sicurezza

3.3 System Call

• Intefaccia tra processo e sistema operativo • Esempio: un programma che copia un file in

uno nuovo

• Operazioni tipiche che richiedono esecuzione di system call

– scrivere sullo schermo/leggere dalla tastiera – passare argomenti ad un programma mandato in

esecuzione

– aprire un file, crearne uno nuovo

62

3.3 System Call

– messaggi all’utente e alla console (operatore) – terminare in modo anomalo

– cancellare un file

– leggere da un file, scrivere su un file – indicazioni di stato riguardanti condizioni di

errore – chiudere i file – terminare con successo

63

3.3 System Call

• Comandi di alto livello/accesso diretto alle system call (syscall), modellate come funzioni

• Passaggi di parametri alle syscall

– registri

– blocco il cui indirizzo è passato come parametro in un registro

Passaggio di parametri via blocco

65

Tipi di system call

• Controllo dei processi

– end, abort, load, execute – create process, terminate process

– get process attributes, set process attributes – wait for time

– wait event, signal event – allocate e free memory

• Caricamento programmi: dove si torna?

– al chiamante ⇒ chiamata di programmi – si eseguono concorrentemente⇒

multiprogrammazione

66

Tipi di system call

• Manipolazione di file

– create file, delete file – open, close

– read, write, reposition

– get file attributes, set file attributes

• Struttura di connessione via open/create + close

Tipi di system call

• Gestione dei dispositivi

– request device, release device – read, write, reposition

– get file attributes, set file attributes – logically attach o detach devices

• Trasparenza rispetto ai file, struttura di connessione

68

Tipi di system call

• Gestione delle informazioni

– get time o date, set time o date – get system data, set system data – get process, file, o device attributes – set process, file, o device attributes

• Time & Date, utenti, processi

69

Tipi di system call

• Comunicazione

– create, delete communication connection – send, receive messages

– transfer status information – attach o detach remote device

• 2 Modelli: Message-Passing - Shared Memory

– Spesso connection oriented, host o process oriented

– Shared Memory: MapMemory per accedere ad aree di altri processi

Message Passing vs Shared Memory

71

3.4 Programmi di Sistema

• Programmi che rendono più conveniente l’ambiente per i programmi e gli utenti

– librerie (ad es. per le syscall) – comandi utente, processi e daemon

• Varie categorie:

– manipolazione dei file, – informazioni di stato, – modifica dei file (text editor), – supporto alla programmazione,

– caricamento ed esecuzione dei programmi, – comunicazioni, programmi applicativi

72

3.4 Programmi di Sistema

• Interprete di comandi è il più caratterizzante, anche quando non fa parte del SO

– l’interprete contiene il codice per eseguire i comandi dell’utente

– i comandi sono (quasi) tutti dei programmi di sistema, mandati in esecuzione dall’interprete – SO deve permettere a un programma di

mandarne in esecuzione un altro

3.5 Struttura del Sistema

• Per tenere sotto controllo la complessità • 3.5.1 Struttura semplice

• Nessuna, perché il sistema è molto semplice, per hw molto limitato.

– Es. MS-DOS

74

3.5.1 Struttura semplice

• Molto limitata, perché il sistema

inizialmente era semplice, su hw semplice. Es. Unix

• Approccio a micro-kernel. Es Mach

75

3.5.2 Approccio a strati

• Hw rende possibile e conveniente la scomposizione in componenti

• Approccio a strati: ogni strato è un oggetto astratto Notare: incapsulamento,

e non perforazione dei livelli (come in DOS),

filtraggio delle chiamate

3.5.2 Approccio a strati

• Poco efficienti → ridurre i livelli, modularizzare in verticale. Es OS/2

77

3.6 Macchine Virtuali

• Utilizzare l’hw in modo da poter usare anche SO diversi contemporaneamente • La macchina virtuale è esattamente identica

(a parte la quantità) alla macchina reale

78

3.6 Macchine Virtuali

• CPU scheduling per multiplexare la CPU, spooling e file system per virtualizzare i dispositivi di I/O (minidisk del VM/370) • Utilizzo sofisticato del dual-mode, sempre

mediando attraverso il monitor di macchina virtuale

• Le istruzioni privilegiate si eseguono molto più lentamente perché sono simulate.

3.6 Macchine Virtuali

• Vantaggi:

– protezione delle risorse

– varietà di SO sulla stessa macchina – facile sviluppo di nuovi SO sulla stessa

macchina

– Stanno tornando di moda per macchine virtuali diverse (Es. Intel su PowerPC)

• Es. Java Virtual Machine, VMware

80

3.7 Progetto e Implementazione

del Sistema

• Notare: Differenza fra obiettivi di utente e di sistema; e sono difficili fa formalizzare • Occorre separazione netta fra politiche e

meccanismi

– politica =:= cosa fare – meccanismo =:= come fare

• Perché?

– Flessibilità: le politiche cambiano, e quindi devono poter cambiare

81

3.7 Progetto e Implementazione

del Sistema

• Sistemi a micro-kernel: nel kernel solo meccanismi

• Allocazione delle risorse & scheduling sono politiche

• Implementazione dei SO: linguaggi di alto livello + assembler

– maggior portabilità – maggior manutenibilità – maggior capacità di evoluzione

3.8 Generazione del Sistema

• Varietà di macchine di una certa classe • Varietà di configurazioni di memoria e di

I/O diversi

• Quale CPU, quanta MP, quali dispositivi di I/O, quali opzioni di SO

– ⇒ configurato e/o generato per ogni sito per mezzo di SysGen

83

3.8 Generazione del Sistema

• Varie alternative per SysGen

– modifica sorgenti

– ricompilare, ambiente di compilazione necessario

– creazione di tavole e selezioni di moduli linkabili

– necessario re-linkare e ambiente di link – tutto table-driven

– il SO contiene sempre tutto il codice, scelta a run-time

84

3.8 Generazione del Sistema

• Differenza di grandezza del SO, generalità del SO, facilità di SysGen

• Caricamento del kernel =:= booting

– 1. Codice in ROM detto programma di bootstrap cerca il kernel su un dispositivo di I/O, lo carica e gli dà il controllo

– 2. Spesso viene caricato un programma di boot più ricco, che si trova in traccia 0 (zero) sul disco di boot o sulla rete, il quale cerca il kernel