Parte 1

1
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
4
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
– CPU inutilizzata!
2
7
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
3
10
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
4
13
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
5
16
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
18
6
19
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
7
22
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
8
25
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
– system call → test sulla causa dell’evento
9
28
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!
10
31
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, memorymapped I/O
Animazione
11
34
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
P
i
ù
v
e
l
o
c
i
P
i
ù
c
a
p
a
c
i
• Velocità implica costo maggiore, capacità
minore, volatilità maggiore
12
37
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
13
40
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)
14
43
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
15
46
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
Uso di una system call
16
49
3. Strutture di SO
• Panoramica generale di
– Componenti ed interconnessioni
– Servizi
– Interfacce
– Programmi di sistema
– Struttura del sistema
– Macchine virtuali
– 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
deadlock
17
52
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
18
55
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
applicazioni distribuite
19
58
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
20
61
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
– via stack
21
64
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
22
67
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
23
70
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
– SO deve permettere di passare argomenti da
programma a programma
24
73
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
di livello inferiore
25
76
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.
26
79
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
27
82
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
sul disco o sulla rete
28