Sistemi operativi: obiettivi e funzionalità

Un SO controlla l’esecuzione dei programmi applicativi e funge da interfaccia tra applicazioni e hardware. Un SO in sintesi ha tre obiettivi:

  • Facilitare l’uso della macchina fornendo una interfaccia amichevole
  • Gestione efficiente: un SO permette di usare le risorse di sistema in modo più efficiente
  • Capacità di evolvere: un SO deve permettere l’efficace sviluppo e test di nuove funzioni di sistema senza che questo influenzi il suo livello di servizio (hardware upgrade, installazione di nuovo hardware, necessità di nuovi servizi, fixes al SO stesso)

Andremo ad analizzare punto per punto questi obiettivi.

Dal punto di vista dell’utente un computer è un insieme di applicazioni; queste applicazioni sono scritte da un programmatore in un linguaggio di alto livello. Se queste applicazioni dovessero essere scritte in termine di linguaggio macchina e dovessero controllare direttamente l’hardware sottostante il compito sarebbe certamente proibitivo. Questo compito viene facilitato da un insieme di funzioni di sistema, le cosiddette librerie di sistema o programmi di utilità di sistema, che forniscono assistenza nella creazione del programma, nella gestione dei file e nel controllo delle periferiche. Questo set di funzioni di base costituiscono in prima istanza il SO che funge così da mediatore tra le esigenze del programmatore e la macchina facilitando in questo modo l’accesso ai servizi e alle funzionalità del sistema. In sintesi il SO fornisce servizi atti a:

  • facilitare lo sviluppo di programmi attraverso ad es editor o debugger, utilità che sebbene non facciano parte del core del SO sono comunque sue parti accessorie identificabili come applicativi mirati al supporto dello sviluppo del software
  • esecuzione dei programmi: a questo scopo una serie di risorse devono essere inizializzate e preparate, file, periferiche; inoltre dati e istruzioni devono essere caricati in memoria. Il SO si fa carico di questi compiti e della loro temporizzazione.
  • accesso alle periferiche I/O: il SO maschera la complessità dei segnali necessari ad istruire queste periferiche riducendo il compito a delle semplici operazioni di Read e Write
  • accesso ai file: non solo il SO deve astrarre le differenze fisiche esistenti tra i diversi sistemi di storage ma anche gestire i problemi derivanti da accessi concorrenti ai medesimi file
  • accesso al sistema: il SO deve provvedere alla gestione delle autorizzazioni per l’accesso alle varie risorse e risolvere eventuali problemi derivanti da contese per le medesime risorse
  • rilevazione degli errori e risposta: il SO deve gestire la varietà di errori derivanti sia dall’hardware, errori di memoria o altro, sia dal software, divisioni per zero o tentativi di accedere a zone riservate di memoria. La risposta del SO deve provvedere a rimuovere l’ostacolo, chiudendo l’applicazione che ha incontrato l’errore senza influenzare le altre applicazioni oppure ritentando una operazione fallita un certo numero di volte o quanto meno fornendo un messaggio che spieghi la fonte dell’errore
  • misura: il SO deve anche raccogliere una serie di statistiche e misurare un insieme di indici di performance del sistema, in modo da poter prevenire eventuali problemi o predisporre eventuali upgrade o ancora affinare la gestione delle risorse
  • ISA, Instruction Set Architecture, è l’insieme di istruzioni in linguaggio macchina, si può vedere come uno strato software che fa da confine tra hardware e software applicativo. Questo a sua volta comprende un ISA user, insieme di istruzioni direttamente accessibili agli applicativi ed un ISA system, istruzioni riservate al SO per la gestione delle risorse
  • ABI, Application Binary Interface, definisce l’interfaccia tra il SO le risorse hardware ed i servizi disponibile in un sistema attraverso ISA (system calls)
  • API, Application Programming Interface, dà accesso alle risorse ed ai servizi attraverso le ISA user. L’utilizzo delle API, disponibili sotto forma di librerie, permette la portabilità di un applicativo da un sistema ad un altro che supporti le medesime API attraverso ricompilazione

About the Author

Carlo Bazzo
Carlo Bazzo è fondatore di Epysoft, una start up tecnologica con sede a Treviso e CTO di Hdemo Network Business Solutions. Puoi contattare Carlo Bazzo su Linkedin.