Sistemas Operativos (SO)

O computador é composto fisicamente pelo hardware, isto é, a CPU, o Disco Rígido, a Memória, a Placa Gráfica, a Impressora, o Teclado, o Rato, a Placa de Rede e inúmeros outros dispositivos que lhe podem ser ligados por portas USB, Firewire, slots PCIe, PCI, etc., de acordo com o que já vimos quando analisámos a Placa Mãe.
Portanto, um programador, quando está a desenvolver um programa tem de saber as características de todo o equipamento com que vai atuar, para que o seu programa consiga interagir com todos os dispositivos do computador: um teclado, um rato, uma impressora, um monitor e muitos outros, específicos do computador em que vai funcionar. Sim, porque podem ser muitos dispositivos e de muitas marcas.
Nesta perspetiva seria frustrante a atividade de programador. Lembro-me de ter programado assim quando fiz um programa profissional para mim no Spectrum 48K em 1980.
Esta é uma das funções do Sistema Operativo (SO), a gestão de dispositivos de Entrada/Saída. Para este efeito o diferentes fabricantes de equipamentos ou componentes fornecem para cada SO um pequeno programa a que se chama Driver, que ensina o SO a lidar com esse equipamento. O programador só emite instruções que têm a ver com a sua intenção global, isto é, imprime, põe no ecrã, guarda no disco, lê no teclado, etc. É o SO que traduz estas instruções nas necessárias para que essa instrução generalista apareça no dispositivo que cumpre essa função nesse computador.
Como é bom ligar aquele sofisticado Gamepad que fomos comprar para melhor jogarmos aquele jogo de que tanto gostamos e perceber que alguns instantes depois o Gamepad está a funcionar, com todos os botões configurados e preparado para interagir com o tal jogo. E o jogo até sabe o nome do Gamepad e as suas características, sem que o seu programador sequer soubesse da sua existência quando fez o jogo.
Generalizando, o SO é uma Interface entre o Hardware o Software e o Utilizador, incluindo nesta definição funções como:

• A já descrita de gestão de Dispositivos de E/S.
• A gestão de ficheiros, o que faz através do seu Sistema de Ficheiros.
• A gestão de Processos
• A gestão da Memória Virtual
• E outras

Quando a D. Maria pensa fazer um bolo de laranja, vai ao seu livro de receitas e tira a receita do bolo de laranja. É como se fosse ao HD buscar o ficheiro Bolo de Laranja, que corresponde ao programa  (ou receita) de como fazer um bolo de laranja. È uma simples receita, ou um programa. Mas, quando a D. Maria começa a executar a receita, começa a usar os recursos de que dispõe na sua cozinha (tigelas, pírex, batedeiras, forno, lava louças, etc.) e o programa começa a transformar-se naquilo que é o seu objetivo, o bolo de laranja. Pois, da receita (programa) até ao bolo, estamos precisamente no processo de confeção do bolo de laranja.
Durante esse processo de confeção, o tipo de língua em que a receita foi escrita não importa (Português, Inglês, Mandarim, ou outras) bem como o tipo, as características, a marca ou o modelo do equipamento em que se executa. Só importam os ingredientes, as suas quantidades, a forma como se misturam e o tempo e temperatura de cozedura.
Portanto, o processo é alheio à língua em que a receita foi escrita e ao equipamento em que é executada.
Processo é aquilo que executa o objetivo de um programa. É a abstração da execução de um programa, alheia às características da máquina onde executa e à linguagem  em que o programa foi desenvolvido.
Espaço de endereçamento, Pilha, Monte e outros serão conceitos ligados com Processo que serão desenvolvidos.
Mas vários processos podem ser executados em simultâneo na cozinha da D. Maria e a isso chama-se multiprocessamento. E a D. Maria percebeu isso rapidamente, pois verificou que enquanto os processos de confeção estavam no fogão ou no forno ela não estava a fazer nada (talvez croché, mas não receitas) e que podia aproveitar esse tempo para ir adiantando outras receitas em espaços e com equipamento não ocupados. De tal forma, o próprio fogão e o forno começaram a ser muito mais utilizados. A D. Maria estava muito satisfeita, porque percebeu que com o mesmo equipamento conseguia confecionar  mais receitas, portanto produzindo mais, processando mais receitas no mesmo espaço de tempo. O croché é que se ia atrasando. Mas crise é crise e croché não enche barriga.
A D. Maria estava a multicozinhar (multiprocessar) várias receitas na sua cozinha, ou seja, estava a executar em simultâneo várias receitas na mesma cozinha. A D. Maria era o SO da sua cozinha. A sua cozinha era a CPU e o equipamento os periféricos. Quando um processo estava em comunicação longa com um periférico (o forno por exemplo) a D. Maria (o SO) retirava esse processo (a execução da receita) da cozinha (a CPU), guardava-o em espera registando o estado em que se encontrava quando o retirou e colocava outra receita (processo) para processamento na cozinha com outros periféricos mais rápidos. Quando o forno fazia Plimm, estava a chamar-lhe a atenção (ao SO) para o facto de que o processo  que estava a executar nesse periférico já estava pronto e que precisava da atenção dela (SO). Então a D. Maria (SO) suspendia a  receita que estava  a executar na cozinha (CPU) e continuava com a primeira, recomeçando-a exatamente no estado em que a tinha deixado e que tinha registado na sua memória.
O mesmo se passa num sistema real, quando um processo por exemplo precisa de aceder ao HD para ir buscar elementos que não tem em memória.
Junto com multiprocessamento falaremos em  comutação de processos, estados de um processo, interrupções e exceções e também abordaremos a organização de um SO.

É também ao SO que compete a gestão de uma execução em multitarefa. Também a D. Maria foi chamada à compreensão deste processo, mas por agora vamos deixá-la sossegada.
Multitarefa é a divisão de um processo em tarefas que podem ser executadas em paralelo concorrendo todas para o mesmo fim.
A programação por multitarefa compete aos programadores. O SO põe ao dispor dos programadores ferramentas de controlo da concorrência entre tarefas e no acesso a regiões críticas dos processos, como sejam variáveis globais por exemplo. Entre essas ferramentas estão os mutex e os semáforos, que iremos tentar apresentar através de um jogo imaginário onde as equipas competidoras vão ser confrontadas com situações de concorrência em que vão necessitar de usar essas ferramentas com vista a poderem rentabilizar a sua participação sem correrem o risco de criarem situações de inconsistência de dados.
Um programa pode estar em execução em simultâneo com outros. Então como é que o programador ou o compilador fazem para atribuir locais de memória para as instruções e dados do seu programa, que saibam não ser coincidentes com as dos outros? Pois é. Aí correm o risco de colocar programas diferentes a concorrerem para os mesmos espaços de memória, pelo que o programa retirado da CPU, quando lá voltasse tinha tudo baralhado.
Por isso mesmo os programadores devem realizar convénios frequentes entre eles para combinarem entre si os espaços de memória que cada um vai utilizar. De preferência em bons hotéis e em regiões turísticas famosas, para compensar o enfadonho que será estar a assistir à discussão do sexo dos anjos perante uma confusão indescritível da qual nunca sairia qualquer solução.
Como solução para esta questão, o SO tomou o lugar desses espaços de convívio e imaginou uma coisa a que chamou Memória Virtual, que dispõe de um espaço de endereçamento da dimensão dos registadores da CPU:

• Para CPU de 32 bits e SO de 32 bits o espaço virtual de endereçamento está limitado aos 32 bits e corresponde a 4 GB.
• Para CPU de 64 bits e SO de 64 bits o espaço virtual de endereçamento está confinado aos 64 bits (16 Exabytes), embora os diversos SO possam impor limitações inferiores.

No desenvolvimento do trabalho sobre Memória Virtual vamos falar de páginas e paginação da memória, de tabelas de páginas, de Pagefile ou Swappfile, da Cache de paginação que é a TLB (Translation Lookaside Buffer), da forma como na realidade é feito o acesso à memória pela CPU, que só conhece endereços virtuais que têm que ser traduzidos para endereços físicos e para mais é melhor lermos o Capítulo, pois este resumo já vai longo.
Para finalizar vamos ver como é feito o acesso à memória por uma CPU core i7 Nehalem, com apresentação das demoras de acesso aos diferentes níveis de busca, conforme o endereço procurado se encontre numa página de tradução na TLB ou não, conforme endereço traduzido se encontre ou não em cache, ou em página em memória principal ou em página no Pagefile.

Ver a síntese global deste trabalho

Inserimos de seguida o índice da edição em livro como forma de descrição dos temas abordados neste Capítulo