I sistemi operativi sono programmi nè più nè meno di ogni altro programma applicativo ed usano le stesse risorse di macchina. Lo scopo però è quello di gestire al meglio le risorse elaborative ed ottenere la migliore efficienza dell'insieme.

Abbiamo già discusso di multiprogrammazione e della sua solo apparente capacità di eseguire contemporaneamente più programmi: in realtà in maniera microscopica viene eseguita una ed una sola sequenza di istruzioni per la quale la CPU viene dedicata. Occorre dunque innanzitutto individuare l'unità elementare di lavoro che possa rappresentare una sequenza logica di istruzioni. Questa unità di lavoro viene identificata in vario modo dai diversi produttori (task, thread ecc.) e per la nostra comodità e per non far torto a nessuno la chiameremo Unità di Lavoro. Il gestore delle UL è dunque il primo componente del sistema operativo che possiamo identificare: esso ha il compito di creare, gestire, mantenere e cancellare un insieme di informazioni in memoria che rappresentano le UL.

Le UL corrispondono a programmi e cioè a sequenze di istruzioni. Poichè la memoria contiene indifferentemente istruzioni e dati, occorre gestire il contenuto della memoria per conoscere in ogni momento quali porzioni di memoria sono assegnate, quali libere e, per quelle assegnate, chi ne è il proprietario. Ci sono tabelle di controllo che contengono questa corrispondenza o, se si vuol dire in altro modo, la mappa dell'utilizzo della memoria. Ecco dunque un altro gestore, il gestore della memoria. 

Poichè la risorsa CPU è unica e una ed una sola UL può essere in controllo occorre che qualcuno decida a chi assegnarla: questo componente prende comunemente il nome di dispatcher. Anche se il termine indica genericamente la capacità di attivare, esso viene comunemente utilizzato nel campo degli elaboratori appunto per indicare quel componente che assegna ad una UL la risorsa CPU. 

Diciamo ora che abbiamo diverse UL disponibili, pronte cioè a prendere il controllo della CPU: come decido a chi darlo? Ci sono diverse tecniche e queste variano principalmente a seconda della complessità delle risorse da gestire. 

Potrei ad esempio utilizzare una tecnica basata sull'assegnazione ciclica della CPU alla prima, poi alla seconda e così via, fino a ricominciare dalla prima quando ho finito la lista disponibile (round robin). Il passare da una all'altra è funzione del rilascio volontario del controllo da parte della UL e/o della scadenza di un tempo preassegnato (time slicing). In questo modo accontento più meno tutte le UL. Questa tecnica viene utilizzata prevalentemente in una situazione ove ogni UL ha un contenuto di CPU (percentuale di CPU rispetto al tempo totale di esecuzione comprensivo del tempo di accesso ai dati) relativamente basso e con una distribuzione relativamente uniforme.

Un'altra tecnica utilizzata è quella prioritaria. In questo caso la lista delle UL viene aggiustata in un preciso ordine e il controllo viene passato sempre all'elemento che risulta il primo ad essere disponibile ad utilizzare la CPU. Questo algoritmo viene applicato nel caso in cui siamo in presenza di UL con un contenuto di CPU abbastanza diversificato e non molto predicibile. Per poter portare ragionevolmente avanti tutte le UL, devo metter in testa quelle che hanno un contenuto di CPU più basso e quindi hanno una probabilità più alta di cedere il controllo a quelle di contenuto più alto e con queste ultime in coda. In questo modo inoltre avrò anche una probabilità maggiore di trovare sempre qualche UL pronta a prendere il controllo. 

Non è facile, con un dispatcher di tipo prioritario, avere sempre la migliore efficienza: una UL nella sua vita elaborativa può avere profili diversi e così passare da un utilizzo di CPU basso ad uno alto e così via. Si può aggiungere intelligenza al dispatcher e tenere una storia del comportamento di ciascuna UL: in tal modo la lista di UL può venire dinamicamente e più o meno frequentemente riarrangiata.

Il dispatcher di tipo prioritario viene invocato sempre e comunque ogniqualvolta avviene una interruzione e si completa ad esempio un'operazione di trasferimento dati e questo parte sempre dall'inizio della lista. La funzione di riaggiustamento di questa lista è quindi di solito asincrona e viene eseguita a tempo e in modo indipendente.

Voglio a questo punto porre una domanda: quando posso immaginare di poter far lavorare la CPU sempre al cento per cento? Quando ho a disposizione un numero sufficiente di UL in memoria e pronte a prendere il controllo. E' chiaro che se io avessi una UL con un contenuto di CPU del 100 per cento, me ne basterebbe una sola, mentre se il contenuto medio di CPU delle UL caricate fosse del 10 per cento, ne dovrei avere 10, e così via. Questo numero viene definito profondità di multiprogrammazione. Più questa aumenta e più utenti avrò in macchina e questo è sia il risultato di una popolazione di UL con un contenuto di CPU basso sia della capacità del sistema operativo di gestire un gran numero di UL (capacità gestionale). D'altra parte questo numero aumenta, a parità di tipologia di programmi, direttamente in funzione della velocità della CPU: ancora una volta troviamo una stretta relazione fra risorse hardware e sistemi operativi. Infatti il semplice aumento di potenza della CPU, in ambienti multiutente, anche a parità di programmi applicativi può porre automaticamente potenziali problemi alle altre parti e di conseguenza richiedere un adeguamento complessivo del sistema. 

Poichè ogni UL è una sequenza di istruzioni che occupa memoria, maggiore sarà il numero di queste e maggiore sarà la dimensione della memoria che li deve contenere. La memoria è, insieme alla CPU e al canale, uno dei tre elementi della macchina di Von Neuman e, come ogni altra risorsa hardware, è di dimensioni finite. Il numero di programmi che possiamo scrivere è teoricamente infinito e così pure la loro dimensione totale.

Come possiamo gestire questa incongruenza? Abbiamo accennato al gestore della memoria: in realtà questo è un poco più complicato di quanto sembri e lasciamo ad un prossimo intervento la discussione su questo tema.

Computer amico mio