Baixe o app para aproveitar ainda mais
Prévia do material em texto
Fundamentos de sistemas operacionais APRESENTAÇÃO Os computadores estão cada vez mais presentes no dia a dia das pessoas, auxiliando em diferentes tarefas. De certo modo, é difícil acreditar que há 60 ou 70 anos os computadores estavam dando seus primeiros passos. Desde então, os computadores se tornaram mais complexos, funcionais e cada vez menores, tudo isso pelo avanço da tecnologia. Dessa forma, ficam questões como: o sistema operacional coordena tudo isso? E o que de fato é o sistema operacional? Nesta Unidade de Aprendizagem, você vai descobrir essas respostas, pois irá aprender o conceito de sistema operacional, como ele funciona e como evoluiu até os dias atuais. Bons estudos. Ao final desta Unidade de Aprendizagem, você deve apresentar os seguintes aprendizados: Definir sistema operacional.• Explicar o funcionamento de um sistema operacional.• Relatar a evolução dos sistemas operacionais.• DESAFIO Os sistemas operacionais permitem a comunicação dos programas com o hardware por meio de uma camada de abstração, a qual repassa os comandos requisitados pelo software ao hardware. Considere a seguinte situação. Você trabalha num projeto de um carro autônomo, na construção de um protótipo que precisa simular os movimentos básicos de um carro, como: virar à direita (90o sentido horário), virar à esquerda (90o sentido anti-horário), acelerar, frear e andar de ré. Cada um desses comandos, para ser executado, precisa de uma sequência de comandos em nível de hardware. Por exemplo, para virar o carro à direita, é necessário rotacionar 45o (em sentido horário) as rodas dianteiras e acionar a aceleração em cada uma rodas. Isso para cada um dos comandos desejados. Além disso, como o projeto pretende que o carro seja autônomo, os comandos de direção não podem ser feitos diretamente no hardware, mas devem ser criadas rotinas para execução de cada comando. Contudo, seu orientador concorda que o uso de rotinas será bom para simplificar os comandos, mas o hardware não entende essas rotinas. Considerando o apresentado, qual solução você pode propor para que o hardware consiga entender as rotinas dos comandos em software? INFOGRÁFICO Os primeiros computadores eram grandes máquinas de processamento de cálculos matemáticos e científicos. Contudo, as etapas de preparação para o processamento com a entrada dos dados e impressão da saída não eram realizadas pelo computador, mas sim pela atividade humana. A introdução do sistema operacional permitiu uma grande evolução no mundo computacional. Isso se deve à criação de uma camada de software, que é o sistema operacional, responsável pela comunicação e pelo gerenciamento dos dispositivos de hardware, provendo abstrações na forma de software, em que os usuários do computador, por meio dos programas, possam interagir com os recursos do computador. No Infográfico, você vai conhecer como o sistema operacional atua entre os programas de usuário e os componentes do hardware. CONTEÚDO DO LIVRO Os sistemas operacionais permitiram um grande um avanço tecnológico no mundo computacional. Em um computador, o sistema operacional é responsável pelo gerenciamento de todos os componentes, permitindo o compartilhamento dos recursos por todos os processos, seja em tempo ou espaço. Para entender mais a fundo como funcionam os sistemas operacionais, no trecho selecionado da obra Sistemas Operacionais: projeto e implementação, você irá conhecer a definição de um sistema operacional, como esse sistema funciona e de que forma ele evoluiu. Boa leitura. T164s Tanenbaum, Andrewa S. Sistemas operacionais [recurso eletrônico] : projeto e implementação / Andrew S. Tanenbaum, Albert S. Woodhull ; tradução João Tortello. – 3. ed. – Dados eletrônicos. – Porto Alegre : Bookman, 2008. Editado também como livro impresso em 2008. ISBN 978-85-7780-285-2 1. Sistemas operacionais. I. Woodhull, Albert S. II. Título. CDU 004.4 Catalogação na publicação: Mônica Ballejo Canto – CRB 10/1023 CAPÍTULO 1 • INTRODUÇÃO 23 particular, ele está livre para escrever seu próprio compilador, se preferir; mas não está livre para escrever sua própria rotina de interrupção de relógio, que faz parte do sistema opera- cional e é normalmente protegida pelo hardware contra tentativas de modifi cação por parte dos usuários. Essa distinção, entretanto, às vezes não é clara nos sistemas embarcados (os quais podem não ter modo núcleo) ou nos sistemas interpretados (como os sistemas baseados em Java, que usam um interpretador em software e não o hardware para isolar os componentes). Contudo, para computadores tradicionais, o sistema operacional é o que executa no modo núcleo. Dito isso, em muitos sistemas existem programas que são executados no modo usuário, mas que ajudam o sistema operacional ou desempenham funções privilegiadas. Por exemplo, freqüentemente existe um programa que permite aos usuários mudarem suas senhas. Esse programa não faz parte do sistema operacional e não é executado no modo núcleo, mas clara- mente executa uma função sigilosa e precisa ser protegido de uma maneira especial. Em alguns sistemas, incluindo o MINIX 3, essa idéia é levada ao extremo, e parte do que é tradicionalmente considerado como sendo o sistema operacional (como o sistema de ar- quivos) é executado em modo usuário (também dito em espaço de usuário) . Em tais sistemas é difícil traçar um limite claro. Tudo que é executado no modo núcleo claramente faz parte do sistema operacional, mas é razoável considerar que alguns programas que são executados fora dele também fazem parte dele ou, pelo menos, estão intimamente associados a ele. Por exemplo, no MINIX 3, o sistema de arquivos é simplesmente um programa C enorme, exe- cutado em modo usuário. Finalmente, acima dos programas de sistema aparecem os programas aplicativos. Esses programas são adquiridos, ou escritos pelos usuários, para resolver seus problemas particula- res, como processamento de textos, planilhas eletrônicas, cálculos de engenharia ou armaze- namento de informações em um banco de dados. 1.1 O QUE É O SISTEMA OPERACIONAL? A maioria dos usuários de computador já teve alguma experiência com um sistema operacio- nal, mas é difícil defi nir precisamente o que é um sistema operacional. Parte do problema é que os sistemas operacionais executam duas funções basicamente não relacionadas, amplian- do os recursos da máquina e de gerenciamento, e dependendo de quem está falando, você ouve mais sobre uma ou outra função. Vamos examinar as duas agora. 1.1.1 O sistema operacional como uma máquina estendida Conforme mencionado anteriormente, a arquitetura (conjunto de instruções, organização da memória, E/S e estrutura do barramento) da maioria dos computadores em nível de lin- guagem de máquina é primitiva e inconveniente para programar, especialmente quanto à E/S. Para tornar esse ponto mais concreto, vamos ver brevemente como é feita a E/S de um disco fl exível usando os controladores de dispositivos compatíveis com o NEC PD765, usados em muitos computadores pessoais baseados em Intel. (Neste livro, usaremos os termos “disco fl exível” e “disquete” indistintamente.) O PD765 tem 16 comandos, cada um deles especifi - cado através da escrita entre 1 e 9 bytes em um registrador de dispositivo. Esses comandos servem para ler e gravar dados, mover o braço do disco, formatar trilhas, assim como para inicializar, monitorar, reconfi gurar e recalibrar o controlador e as unidades de disco. Os comandos mais básicos são read e write, cada um deles exigindo 13 parâmetros, empacotados em 9 bytes. Esses parâmetros especifi cam itens como o endereço do bloco de 24 SISTEMAS OPERACIONAIS disco a ser lido, o número de setores por trilha, o modo de gravação usado na mídia física, o espaçamento do intervalo entre setores (interleaving) e o que fazer com uma marca de endereço de dados excluídos. Se você não entendeu nada desse discurso, não se preocupe;é essa exatamente a questão – tudo é muito esotérico. Quando a operação está terminada, o controlador retorna 23 campos de status e de erro, empacotados em 7 bytes. Como se não bas- tasse, o programa do disquete também precisa saber constantemente se o motor está ligado ou desligado. Se o motor estiver desligado, deverá ser ligado (com uma longa demora para sua inicialização) antes que os dados possam ser lidos ou escritos. Entretanto, o motor não pode fi car ligado por muito tempo, senão o disquete irá desgastar-se. Assim, o programa é obrigado a tratar do compromisso entre longos atrasos na inicialização e o desgaste dos disquetes (e a perda dos dados neles contidos). Sem entrar nos detalhes reais, deve estar claro que um programador médio provavel- mente não desejará se envolver intimamente com a programação de disquetes (ou de discos rígidos, que são igualmente complexos e bastante diferentes). Em vez disso, o programador deseja tratar com uma abstração simples e de alto nível. No caso dos discos, uma abstração típica seria o disco conter um conjunto de arquivos nomeados. Cada arquivo pode ser aberto para leitura ou escrita, em seguida lido ou escrito e fi nalmente fechado. Detalhes como se a escrita deve ou não usar modulação em freqüência e qual é o estado atual do motor não de- vem aparecer na abstração apresentada ao usuário (programador). Naturalmente, o programa que oculta do usuário a realidade sobre o hardware e apre- senta uma visão bela e simples de arquivos nomeados que podem ser lidos e escritos é o sistema operacional. Assim como o sistema operacional isola o usuário do hardware do disco e apresenta uma interface simples orientada para arquivos, também oculta muitos detalhes desagradáveis relativos a interrupções, temporizadores, gerenciamento de memória e outros recursos de mais baixo nível. Em cada caso, a abstração oferecida pelo sistema operacional é mais simples e mais fácil de usar do que aquela oferecida pelo hardware subjacente. Sob esse ponto de vista, a função do sistema operacional é apresentar ao usuário o equivalente a uma máquina estendida, ou máquina virtual, mais fácil de programar do que o hardware que a compõe. O modo como o sistema operacional atinge esse objetivo é uma longa história, que estudaremos em detalhes por todo este livro. Para resumir em poucas palavras, o sistema operacional fornece uma variedade de serviços que os programas podem obter usando instruções especiais denominadas chamadas de sistema. Posteriormente, neste capítulo, examinaremos algumas das chamadas de sistema mais comuns. 1.1.2 O sistema operacional como gerenciador de recursos O conceito do sistema operacional como fornecendo principalmente uma interface conve- niente para seus usuários é uma visão top-down (de cima para baixo). Uma visão alternativa, botton-up (de baixo para cima), sustenta que o sistema operacional existe para gerenciar todas as partes de um sistema complexo. Os computadores modernos são compostos de pro- cessadores, memórias, temporizadores, discos, mouses, interfaces de rede, impressoras e uma ampla variedade de outros dispositivos. Na visão alternativa, a tarefa do sistema operacional é fornecer uma alocação ordenada e controlada dos processadores, memórias e dispositivos de E/S entre os vários programas que concorrem por eles. Imagine o que aconteceria se três programas sendo executados em um computador tentassem todos imprimir suas saídas simultaneamente na mesma impressora. As primeiras linhas da saída impressa poderiam ser do programa 1, as linhas seguintes do programa 2 e, então, algumas do programa 3 etc. O resultado seria o caos. O sistema operacional pode trazer ordem ao caos em potencial, armazenando no disco, por programa, toda a saída desti- CAPÍTULO 1 • INTRODUÇÃO 25 nada à impressora. Quando um programa tiver terminado, o sistema operacional envia para a impressora a sua saída armazenada no arquivo em disco, enquanto, ao mesmo tempo, um outro programa poderá continuar gerando mais saída, ignorando o fato de que ela não está realmente indo para a impressora (ainda). Quando um computador (ou uma rede) tem vários usuários, a necessidade de gerenciar e proteger a memória, dispositivos de E/S e outros recursos é ainda maior, pois os usuá- rios poderiam interferir uns com os outros. Além disso, os usuários freqüentemente precisam compartilhar não apenas o hardware, mas também informações (arquivos, bancos de dados etc.). Em resumo, essa visão do sistema operacional sustenta que sua principal tarefa é con- trolar quem está usando qual recurso, garantir os pedidos de recursos, medir a utilização e mediar pedidos confl itantes de diferentes programas e usuários. O gerenciamento de recursos inclui a multiplexação (compartilhamento) de recursos de duas maneiras: no tempo e no espaço. Quando um recurso é multiplexado no tempo, diferen- tes programas ou usuários o utilizam por turnos: primeiro um deles utiliza o recurso, depois outro e assim por diante. Por exemplo, com apenas uma CPU e vários programas que queiram ser executados nela, o sistema operacional primeiramente aloca a CPU para um programa e, depois, após o programa ter executado o sufi ciente, outro programa utiliza a CPU, depois outro e, fi nalmente, o primeiro programa novamente. Determinar como o recurso é multiple- xado no tempo – quem vem em seguida e por quanto tempo – é tarefa do sistema operacional. Outro exemplo de multiplexação no tempo é o compartilhamento da impressora. Quando várias tarefas de impressão são enfi leiradas em uma única impressora, uma decisão precisa ser tomada com relação a qual das tarefas deve ser impressa a seguir. O outro tipo de multiplexação é a no espaço. Em vez dos clientes atuarem por turnos, cada um deles recebe parte do recurso. Por exemplo, normalmente, a memória principal é dividida entre vários programas que estejam em execução para que cada um possa estar residente ao mesmo tempo (por exemplo, para utilizar a CPU por turnos). Supondo que haja memória sufi ciente para conter múltiplos programas, é mais efi ciente manter vários progra- mas na memória de uma vez do que alocar toda ela para um único programa, especialmente se ele precisar apenas de uma pequena fração do total. É claro que isso levanta problemas de imparcialidade, proteção etc., e fi ca por conta do sistema operacional resolvê-los. Outro recurso multiplexado no espaço é o disco (rígido). Em muitos sistemas, um único disco pode conter arquivos de muitos usuários ao mesmo tempo. Alocar espaço em disco e controlar quem está usando quais blocos de disco é uma típica tarefa de gerenciamento de recursos do sistema operacional. 1.2 HISTÓRIA DOS SISTEMAS OPERACIONAIS Os sistemas operacionais vêm evoluindo ao longo dos anos. Nas seções a seguir, veremos re- sumidamente alguns dos destaques. Como, historicamente, os sistemas operacionais têm sido intimamente ligados à arquitetura dos computadores em que são executados, examinaremos as sucessivas gerações de computadores para vermos como eram seus sistemas operacionais. Esse mapeamento das gerações de sistema operacional para gerações de computador é gros- seiro, mas oferece uma base que de outra forma não teríamos. O primeiro computador digital foi projetado pelo matemático inglês Charles Babbage (1792–1871). Embora Babbage tenha gasto a maior parte de sua vida e de sua fortuna tentan- do construir sua “máquina analítica”, nunca conseguiu fazê-la funcionar corretamente, pois ela era puramente mecânica e a tecnologia de seu tempo não podia produzir as rodas e en- grenagens exigidas com a alta precisão que necessitava. É desnecessário dizer que a máquina analítica não tinha sistema operacional. 26 SISTEMAS OPERACIONAIS Como um dado histórico interessante, Babbage percebeu que precisaria de software para sua máquina analítica; assim, contratou como a primeira programadora do mundo, uma jovem chamada Ada Lovelace, que era fi lha do famoso poeta britânico Lord Byron. A lingua-gem de programação Ada® recebeu esse nome em sua homenagem. 1.2.1 A primeira geração (1945–1955): válvulas e painéis de conectores Depois dos esforços mal-sucedidos de Babbage, pouco progresso foi feito na construção de computadores digitais até a II Guerra Mundial. Em meados da década de 40, Howard Aiken, da Universidade de Harvard, John von Neumann, do Instituto de Estudos Avan- çados de Princeton, J. Presper Eckert e John Mauchley, da Universidade da Pensilvânia, e Konrad Zuse, na Alemanha, entre outros, tiveram êxito na construção de máquinas de calcular. As primeiras delas usavam relés mecânicos, mas eram muito lentas, com tempos de ciclo medidos em segundos. Posteriormente, os relés foram substituídos por válvulas a vácuo. Essas máquinas eram enormes, ocupavam salas inteiras com dezenas de milhares de válvulas, mas ainda eram milhões de vezes mais lentas do que os computadores pes- soais mais baratos de hoje. Naqueles tempos, um único grupo de pessoas projetava, construía, programava, opera- va e mantinha cada máquina. Toda a programação era feita em linguagem de máquina pura, freqüentemente interligando fi os através de painéis de conectores para controlar as funções básicas da máquina. As linguagens de programação não existiam (nem mesmo a linguagem assembly). Ninguém tinha ouvido falar de sistemas operacionais. O modo de operação normal era o programador reservar um período de tempo em uma folha de reserva afi xada na parede, depois descer à sala da máquina, inserir seu painel de conectores no computador e passar as próximas horas esperando que nenhuma das quase 20.000 válvulas queimasse durante a exe- cução. Praticamente todos os problemas resolvidos eram cálculos numéricos simples, como a geração de tabelas de senos, co-senos e logaritmos. No início da década de 50, a rotina havia melhorado um pouco, com a introdução dos cartões perfurados. Agora era possível, em vez de usar painéis de conectores, escrever progra- mas em cartões de papel e lê-los; fora isso, o procedimento era o mesmo. 1.2.2 A segunda geração (1955–1965): transistores e sistemas de lote A introdução do transistor, em meados da década de 50, mudou o quadro radicalmente. Os computadores se tornaram confi áveis o bastante para serem fabricados e vendidos para clien- tes com a expectativa de que continuariam a funcionar por tempo sufi ciente para realizarem algum trabalho útil. Pela primeira vez, havia uma separação clara entre projetistas, construto- res, operadores, programadores e pessoal de manutenção. Essas máquinas, agora chamadas de computadores de grande porte (ou mainframes), eram postas em salas especiais com ar-condicionado e com equipes de operadores profi ssio- nais especialmente treinadas para mantê-las funcionando. Somente grandes empresas, impor- tantes órgãos do governo ou universidades podiam arcar com seu preço, na casa dos milhões de dólares. Para executar um job (tarefa), isto é, um programa ou um conjunto de programas, um programador primeiro escrevia o programa no papel (em FORTRAN ou possivelmente até em linguagem assembly) e depois o transformava em cartões perfurados. Então, ele leva- va a pilha de cartões para a sala de submissão de jobs, o entregava para um dos operadores e ia tomar café até que a saída estivesse pronta. Quando o computador terminava o job que estava executando, um operador ia até a impressora, destacava a saída impressa e a levava para uma sala de saída, para que o programador pudesse pegá-la posteriormente. Então, o operador pegava uma das pilhas de cartões que tinham sido trazidas para a sala de submissão CAPÍTULO 1 • INTRODUÇÃO 27 e os inseria na máquina de leitura. Se o compilador FORTRAN fosse necessário, o operador teria que pegá-lo em um gabinete de arquivos e inseri-lo para leitura. Enquanto os operadores andavam pelas salas da máquina, de submissão e de saída, o computador fi cava ocioso. Dado o alto custo do equipamento, não é de surpreender que as pessoas procurassem rapidamente maneiras de reduzir o tempo desperdiçado. A solução geralmente adotada era o sistema de processamento em lotes (batch system). A idéia era reunir em uma bandeja (tray) um con- junto de jobs da sala de submissão e então lê-los em uma fi ta magnética usando um compu- tador relativamente pequeno e barato, como o IBM 1401, que era muito bom para ler cartões, copiar fi tas e imprimir a saída, mas péssimo para cálculos numéricos. Outras máquinas muito mais caras, como o IBM 7094, eram usadas para a computação de fato. Essa situação aparece na Figura 1-2. 1401 7094 1401 (a) (b) (c) (d) (e) (f) Leitora de cartões Unidade de fita Fita de entrada Fita de saída Fita de sistema Impressora Figura 1-2 Um sistema de processamento em lotes primitivo. (a) Os programadores trazem os cartões para o 1401. (b) O 1401 lê o lote de jobs na fi ta. (c) O operador leva a fi ta de en- trada para o 7094. (d) O 7094 realiza a computação. (e) O operador leva a fi ta de saída para o 1401. (f) O 1401 imprime a saída. Após cerca de uma hora de leitura de lotes de jobs, a fi ta era rebobinada e levada para a sala da máquina, onde era montada em uma unidade de fi ta. O operador carregava então um programa especial (o ancestral do sistema operacional de hoje), que lia o primeiro job da fi ta e a executava. A saída era gravada em uma segunda fi ta, em vez de ser impressa. Depois que cada job terminava, o sistema operacional lia automaticamente o próximo job da fi ta e começava a executá-lo. Quando o lote inteiro estava pronto, o operador removia as fi tas de entrada e saída, substituía a fi ta de entrada pelo próximo lote e levava a fi ta de saída para um 1401 imprimir off line (isto é, não conectado ao computador principal). A estrutura típica de um job aparece na Figura 1-3. Ele começava com um cartão $JOB, especifi cando o tempo de execução máximo, em minutos, o número da conta a ser cobrada e o nome do programador. Em seguida, vinha um cartão $FORTRAN, instruindo o sistema operacional a carregar o compilador FORTRAN da fi ta de sistema. Depois, vinha o programa a ser compilado e, então, um cartão $LOAD, orientando o sistema operacional a carregar o programa-objeto recém compilado. (Freqüentemente, os programas compilados eram gravados em fi tas virgens e tinham de ser carregados explicitamente.) Em seguida, vinha o cartão $RUN, instruindo o sistema operacional a executar o programa com os dados que o seguiam. Finalmente, o cartão $END marcava o fi m do job. Esses cartões de controle primitivos foram os precursores das linguagens de controle de jobs modernos e dos interpre- tadores de comandos. Grandes computadores de segunda geração eram usados principalmente para cálcu- los científi cos e de engenharia, como a solução de equações diferenciais parciais que fre- qüentemente ocorrem na física e na engenharia. Eles eram programados principalmente em 28 SISTEMAS OPERACIONAIS FORTRAN e em linguagem assembly. Sistemas operacionais típicos eram o FMS (o Fortran Monitor System) e o IBSYS, sistema operacional da IBM para o 7094. 1.2.3 A terceira geração (1965–1980): CIs e multiprogramação No início da década de 60, a maioria dos fabricantes de computadores tinha duas linhas de produtos distintas e totalmente incompatíveis. Por um lado, havia os computadores científi cos de grande escala, baseados em palavras binárias, como o 7094, que eram utilizados para cál- culos numéricos em ciência e engenharia. Por outro, havia os computadores comerciais, ba- seados em caracteres, como o 1401, que eram amplamente usados por bancos e companhias de seguro para ordenar e imprimir fi tas. Desenvolver, manter e comercializar duas linhas de produtos completamente diferen- tes era uma proposta cara para os fabricantes de computadores. Além disso, muitos clientes novos necessitavam, inicialmente, de uma máquina pequena, mas posteriormente cresciam e queriam uma máquina maior, que tivesse a mesma arquitetura da atual para poderem executar todos os seus programasantigos, só que mais rapidamente. A IBM tentou resolver esses dois problemas de uma só vez introduzindo o System/360. O 360 era uma série de máquinas de software compatível que variavam desde a capacidade de um 1401 até um muito mais poderoso do que o 7094. As máquinas diferiam apenas no preço e no desempenho (capacidade máxima de memória, velocidade do processador, número de dispositivos de E/S permitidos etc.). Como todas as máquinas tinham a mesma arquitetura e o mesmo conjunto de instruções, os programas escritos para uma podiam ser executados em todas as outras, pelo menos teoricamente. Além disso, o 360 foi projetado para realizar computação científi ca (isto é, numérica) e comercial. Assim, uma única família de máquinas podia satisfazer as necessidades de todos os clientes. Nos anos seguintes, a IBM lançou novos produtos sucessores usando tecnologia mais moderna, compatíveis com a linha 360, conheci- dos como as séries 370, 4300, 3080, 3090 e Z. O 360 foi a primeira linha de computadores importante a usar circuitos integrados (CIs), oferecendo assim uma importante vantagem de preço/desempenho em relação às má- quinas de segunda geração, que eram construídas a partir de transistores individuais. Ele teve sucesso imediato e a idéia de uma família de computadores compatíveis logo foi ado- $JOB, 10,6610802, MARVIN TANENBAUM $FORTRAN $LOAD $RUN $END Programa Fortran Dados do programa Figura 1-3 Estrutura típica de um job FMS. CAPÍTULO 1 • INTRODUÇÃO 29 tada por todos os outros principais fabricantes. As descendentes dessas máquinas ainda são empregadas nos centros de computação atuais. Hoje em dia, elas são freqüentemente usadas para gerenciamento de bancos de dados grandes (por exemplo, para sistemas de reservas de passagens aéreas) ou como servidores de sites web que precisam processar milhares de pedidos por segundo. A maior força da idéia de “uma família” foi ao mesmo tempo sua maior fraqueza. A intenção era que todo software, incluindo o sistema operacional, o OS/360, funcionasse em todos os modelos. Ele tinha que funcionar em sistemas pequenos, que freqüentemente apenas substituíam os 1401 para copiar cartões em fi ta, e em sistemas muito grandes, que muitas ve- zes substituíam os 7094 para fazer previsão do tempo e outros cálculos pesados. Ele tinha que ser bom em sistemas com poucos periféricos e em sistemas com muitos periféricos. Tinha que funcionar em ambientes comerciais e em ambientes científi cos. Acima de tudo, ele tinha que ser efi ciente em todos esses diferentes usos. Não havia como a IBM (ou quem quer que fosse) escrever um software para atender a todos esses requisitos confl itantes. O resultado foi um sistema operacional enorme e extraor- dinariamente complexo, provavelmente duas ou três vezes maior do que o FMS. Ele consistia em milhões de linhas de linguagem assembly, escritas por milhares de programadores, e con- tinha milhares e milhares de erros, que necessitavam um fl uxo contínuo de novas versões na tentativa de corrigi-los. Cada nova versão corrigia alguns erros e introduzia outros, de modo que o número de erros provavelmente permanecia constante com o tempo. Posteriormente, um dos projetistas do OS/360, Fred Brooks, escreveu um livro espiri- tuoso e incisivo descrevendo suas experiências com o OS/360 (Brooks, 1995). Embora seja impossível resumir o livro aqui, basta dizer que a capa mostra uma manada de animais pré- históricos atolados em uma vala de alcatrão. A capa do livro de Silberschatz et al. (2004) faz uma comparação semelhante, sobre o fato de os sistemas operacionais serem dinossauros. Apesar de seu tamanho enorme e de seus problemas, o OS/360 e os sistemas operacio- nais de terceira geração semelhantes, produzidos por outros fabricantes de computadores, sa- tisfi zeram a maioria de seus clientes razoavelmente bem. Eles também popularizaram várias técnicas importantes, ausentes nos sistemas operacionais de segunda geração. Provavelmente a mais importante delas foi a multiprogramação. No 7094, quando o job corrente fazia uma pausa para esperar a conclusão de uma operação de fi ta, ou de outro dispositivo de E/S, a CPU simplesmente fi cava ociosa até que a operação terminasse. No caso de cálculos científi cos, que exigem muito da CPU, as operações de E/S não são freqüentes, de modo que esse tempo desperdiçado não é signifi cativo. No caso do processamento de dados comerciais, o tempo de espera pelas operações de E/S freqüentemente chegava a 80 ou 90 porcento do tempo total; portanto, algo tinha que ser feito para evitar que a CPU (cara) fi casse tão ociosa. A solução desenvolvida foi dividir a memória em várias partições, com um job diferente em cada partição, como mostra a Figura 1-4. Enquanto um job estava esperando a conclusão da operação de E/S, outro podia usar a CPU. Se jobs sufi cientes pudessem ser mantidos si- Job 3 Job 2 Job 1 Sistema operacional Partições de memória Figura 1-4 Um sistema de multiprogramação com três jobs na memória. 30 SISTEMAS OPERACIONAIS multaneamente na memória principal, a CPU poderia fi car ocupada praticamente 100% do tempo. Manter vários jobs simultâneos, com segurança, em memória, exige hardware espe- cial para proteger cada um deles, evitando que um interfi ra e cause danos no outro, mas o 360 e outros sistemas de terceira geração estavam equipados com esse hardware. Outro recurso importante apresentado nos sistemas operacionais de terceira geração foi a capacidade de ler jobs de cartões para o disco assim que eram trazidos para a sala do computador. Então, quando um job em execução acabava, o sistema operacional podia car- regar um novo job do disco na partição, agora vazia, e executá-lo. Essa técnica é chamada de spooling (de Simultaneous Peripheral Operation On Line – Operação Periférica Simultânea On-line) e também era usada para saída. Com o spooling, os 1401 não eram mais necessários e acabava grande parte do trabalho de carga das fi tas. Embora os sistemas operacionais de terceira geração fossem convenientes para cálculos científi cos pesados e execuções de processamento de dados comerciais de grande volume, ba- sicamente eles ainda eram sistemas de lote. Muitos programadores sentiam falta dos tempos da primeira geração, quando eles tinham a máquina toda para si por algumas horas e, assim, podiam depurar seus programas rapidamente. Com os sistemas de terceira geração, o tempo entre submeter um job e receber a saída era freqüentemente de várias horas, de modo que uma vírgula colocada em lugar errado podia fazer uma compilação falhar e o programador perder metade do dia. Essa necessidade de um tempo de resposta curto abriu caminho para o compartilha- mento do tempo (time sharing), uma variante da multiprogramação na qual cada usuário tem um terminal on-line. Em um sistema de tempo compartilhado, se 20 usuários estivessem conectados e 17 deles estivessem pensando, conversando ou tomando café, a CPU podia ser alocada por turnos para os três jobs que quisessem o serviço. Como as pessoas que depuram programas normalmente utilizam comandos curtos (por exemplo, compilar uma procedure† de cinco páginas) em vez de longos (por exemplo, ordenar um arquivo de um milhão de registros), o computador pode oferecer um serviço rápido e interativo para vários usuários e também trabalhar em segundo plano (background) com jobs grandes em lotes, quando a CPU estiver ociosa. O primeiro sistema sério de compartilhamento de tempo, o CTSS (Compatible Time Sharing System), foi desenvolvido no M.I.T. em um 7094 especialmente modifi cado (Corbató et al., 1962). Entretanto, o compartilhamento de tempo não se tornou popular até que o hardware de proteção necessário se tornou difundido, durante a terceira geração. Após o sucesso do sistema CTSS, o MIT, o Bell Labs e a General Electric (na época, um importante fabricante de computadores) decidiram dedicar-se ao desenvolvimento de um “computer utility”*, uma máquina que suportaria centenas de usuáriosde tempo compartilha- do simultaneamente. Seu modelo era o sistema de distribuição de eletricidade – quando preci- sa de energia elétrica, você simplesmente insere um plugue na tomada da parede e, dentro do possível, toda a energia que precisar estará lá. Os projetistas desse sistema, conhecido como MULTICS (MULTiplexed Information and Computing Service – Serviço de Computação e Informação Multiplexado), imaginaram uma única máquina enorme fornecendo poder de computação para todos na região de Boston. A idéia de que máquinas muito mais poderosas do que seu computador de grande porte GE-645 seriam vendidas aos milhões por menos de mil dólares, apenas 30 anos depois, era pura fi cção científi ca, como seria nos dias de hoje a idéia de trens supersônicos e transatlânticos submarinos. † Usaremos os termos procedure, procedimento, sub-rotina e função indistintamente neste livro. * N. de R. T.: Utility neste caso tem o sentido de um serviço público, indicando um recurso computacional amplamente dispo- nível. CAPÍTULO 1 • INTRODUÇÃO 31 O MULTICS foi um sucesso misto. Ele foi projetado para suportar centenas de usuários em uma máquina apenas ligeiramente mais poderosa do que um PC baseado no Intel 80386, embora tivesse muito mais capacidade de E/S. Isso não é tão louco quanto parece, pois na- quela época as pessoas sabiam escrever programas pequenos e efi cientes, uma habilidade que subseqüentemente foi perdida. Houve muitas razões para o MULTICS não tomar conta do mundo, não sendo a menor delas, o fato de ter sido escrito em PL/I e que o compilador de PL/I estava anos atrasado e mal funcionava quando fi nalmente chegou ao mercado. Além disso, o MULTICS era enormemente ambicioso para sua época, semelhantemente à máquina analítica de Charles Babbage no século XIX. O MULTICS introduziu muitas idéias embrionárias na literatura sobre computadores, mas transformá-lo em um produto sério e em um sucesso comercial foi muito mais difícil do que o esperado. O Bell Labs retirou-se do projeto e a General Electric desistiu completamen- te do negócio de computadores. Entretanto, o M.I.T. persistiu e fi nalmente fez o MULTICS funcionar. Por fi m, ele foi vendido como um produto comercial pela empresa que adquiriu o ramo de computadores da GE (a Honeywell) e instalado por cerca de 80 empresas e univer- sidades importantes do mundo todo. Embora em número pequeno, os usuários do MULTICS eram extremamente leais. A General Motors, a Ford e a Agência de Segurança Nacional dos EUA, por exemplo, só desligaram seus sistemas MULTICS no fi nal dos anos 90. O último MULTICS que estava em funcionamento, no Departamento de Defesa Nacional canadense, foi desligado em outubro de 2000. Apesar de sua falta de sucesso comercial, o MULTICS teve uma enorme infl uência sobre os sistemas operacionais subseqüentes. Existem muitas in- formações sobre ele (Corbató et al., 1972; Corbató e Vyssotsky, 1965; Daley e Dennis, 1968; Organick, 1972; e Saltzer, 1974). Ele também tem um site web ainda ativo, www.multicians. org, com muitas informações sobre o sistema, seus projetistas e seus usuários. Não se ouve falar mais da expressão computer utility, mas a idéia ganhou vida nova recentemente. Em sua forma mais simples, os PCs ou estações de trabalho (PCs de topo de linha) em uma empresa, ou em uma sala de aula, podem estar conectados, por meio de uma rede local (LAN), a um servidor de arquivos no qual todos os programas e dados estão ar- mazenados. Então, um administrador precisa instalar e proteger apenas um conjunto de pro- gramas e dados, e pode reinstalar facilmente software local em um PC ou estação de trabalho que não esteja funcionando bem, sem se preocupar com a recuperação ou com a preservação de dados locais. Em ambientes mais heterogêneos, foi desenvolvida uma classe de software chamada middleware para fazer a ligação entre usuários locais e arquivos e entre programas e bancos de dados armazenados em servidores remotos. O middleware faz os computadores in- terligados em rede parecerem locais para os PCs ou para as estações de trabalho dos usuários individuais e apresenta uma interface uniforme com o usuário, mesmo que haja uma ampla variedade de servidores, PCs e estações de trabalho diferentes em uso. A World Wide Web é um exemplo. Um navegador web apresenta documentos para um usuário de maneira unifor- me e um documento visualizado no navegador de um usuário pode ser composto por texto de um servidor e elementos gráfi cos de um outro, apresentados em um formato determinado por uma folha de estilos (style sheets) de um terceiro servidor. Normalmente, as empresas e universidades utilizam uma interface web para acessar bancos de dados e executar programas em um computador em outro prédio ou mesmo em outra cidade. O middleware parece ser o sistema operacional de um sistema distribuído, mas na realidade não é um sistema ope- racional e esse assunto está fora dos objetivos deste livro. Para ver mais informações sobre sistemas distribuídos, consulte Tanenbaum e Van Steen (2002). Outro desenvolvimento importante durante a terceira geração foi o fenomenal cresci- mento dos minicomputadores, começando com o PDP-1 da DEC (Digital Equipment Com- pany), em 1961. O PDP-1 tinha apenas 4K de palavras de 18 bits, mas a US$120.000 por 32 SISTEMAS OPERACIONAIS máquina (menos de 5% do preço de um 7094), foi um grande sucesso de vendas. Para certos tipos de trabalho não numéricos, ele era quase tão rápido quanto o 7094 e deu origem a toda uma nova indústria. Rapidamente, foi seguido por uma série de outros PDPs (ao contrário da família da IBM, todos incompatíveis), culminando no PDP-11. Um dos cientistas da computação do Bell Labs, que tinha trabalhado no projeto do MULTICS, Ken Thompson, encontrou um pequeno minicomputador PDP-7 que ninguém usava e começou a escrever uma versão monousuário simplifi cada do MULTICS. Posterior- mente, esse trabalho transformou-se no sistema operacional UNIX, que se tornou popular no mundo acadêmico, entre órgãos do governo e em muitas empresas. A história do UNIX foi contada em outros textos (por exemplo, Salus, 1994). Como o código-fonte estava amplamente disponível, várias organizações desenvolveram suas próprias versões (incompatíveis), que levaram ao caos. Duas versões importantes foram desenvolvi- das, o System V, da AT&T, e a BSD (Berkeley Software Distribution), da Universidade da Califórnia, em Berkeley. Elas também tiveram pequenas variantes, agora incluindo FreeBSD, OpenBSD e NetBSD. Para tornar possível escrever programas que pudessem ser executados em qualquer sistema UNIX, o IEEE desenvolveu um padrão para o UNIX, chamado POSIX, que a maioria das versões de UNIX agora o suportam. O padrão POSIX defi ne uma interfa- ce mínima de chamadas de sistema que os sistemas UNIX compatíveis devem suportar. Na verdade, agora, outros sistemas operacionais também oferecem suporte a interface POSIX. As informações necessárias para se escrever software compatível com o padrão POSIX estão disponíveis em livros (IEEE, 1990; Lewine, 1991) e on-line, como a “Single UNIX Specifi ca- tion” do Open Group, que se encontra no endereço www.unix.org. Posteriormente, neste capí- tulo, quando nos referirmos ao UNIX, incluímos também todos esses sistemas, a não ser que mencionemos de outra forma. Embora sejam diferentes internamente, todos eles suportam o padrão POSIX; portanto, para o programador, eles são bastante semelhantes. 1.2.4 A quarta geração (1980–hoje): computadores pessoais Com o desenvolvimento dos circuitos LSI (Large Scale Integration – integração em larga escala), chips contendo milhares de transistores em um centímetro quadrado de silício, surgiu a era do computador pessoal baseado em microprocessador. Em termos de arquitetura, os computadores pessoais (inicialmente chamados de microcomputadores) não eram muito diferentes dos minicomputadores da classe PDP-11, mas em termos de preço, eles certamente eram diferentes. O minicomputador também tornoupossível que um departamento de uma empresa ou universidade tivesse seu próprio computador. O microcomputador tornou possí- vel que uma pessoa tivesse seu próprio computador. Havia várias famílias de microcomputadores. Em 1974, a Intel apareceu com o 8080, o primeiro microprocessador de 8 bits de propósito geral. Diversas empresas produziram sistemas completos usando o 8080 (ou o microprocessador compatível da Zilog, o Z80) e o sistema operacional CP/M (Control Program for Microcomputers), de uma empresa cha- mada Digital Research, foi amplamente usado neles. Muitos programas aplicativos foram escritos para executar no CP/M e ele dominou o mundo da computação pessoal por cerca de 5 anos. A Motorola também produziu um microprocessador de 8 bits, o 6800. Um grupo de engenheiros deixou a Motorola para formar a MOS Technology e fabricar a CPU 6502, após a Motorola ter rejeitado as melhorias sugeridas por eles para o 6800. O 6502 foi a CPU de vários sistemas antigos. Um deles, o Apple II, se tornou um importante concorrente dos sis- temas CP/M nos mercados doméstico e educacional. Mas o CP/M era tão popular que muitos proprietários de computadores Apple II adquiriram placas com o coprocessador Z-80 para executar CP/M, pois a CPU 6502 não era compatível com este sistema operacional. As pla- CAPÍTULO 1 • INTRODUÇÃO 33 cas CP/M eram comercializadas por uma pequena empresa chamada Microsoft, que também tinha um nicho de mercado, fornecendo interpretadores BASIC, usado por vários microcom- putadores que executavam o CP/M. A geração seguinte de microprocessadores foram os sistemas de 16 bits. A Intel apare- ceu com o 8086 e, no início dos anos 80, a IBM projetou o IBM PC utilizando o 8088 da Intel (internamente, um 8086, com um caminho de dados externo de 8 bits). A Microsoft ofereceu à IBM um pacote que incluía o BASIC e um sistema operacional, o DOS (Disk Operating System), originalmente desenvolvido por outra empresa – a Microsoft comprou o produto e contratou o autor original para aprimorá-lo. O sistema revisado foi chamado de MS-DOS (MicroSoft Disk Operating System) e rapidamente dominou o mercado do IBM PC. O CP/M, o MS-DOS e o Apple DOS eram todos sistemas de linha de comando: os usuários digitavam comandos no teclado. Anos antes, Doug Engelbart, do Stanford Research Institute, tinha inventado a GUI (Graphical User Interface – interface gráfi ca com o usuá- rio), contendo janelas, ícones, menus e mouse. Steve Jobs, da Apple, viu a possibilidade de um computador pessoal realmente amigável (para usuários que não sabiam nada sobre com- putadores e não queriam aprender) e o Macintosh da Apple foi anunciado no início de 1984. Ele usava a CPU 68000 de 16 bits da Motorola e tinha 64 KB de memória ROM (Read Only Memory – memória somente de leitura), para suportar a GUI. Com o passar dos anos, o Ma- cintosh evoluiu. As CPUs subseqüentes da Motorola eram verdadeiros sistemas de 32 bits e posteriormente a Apple mudou para as CPUs PowerPC da IBM, com arquitetura RISC de 32 bits (e, posteriormente, 64 bits). Em 2001, a Apple fez uma mudança importante no sistema operacional, lançando o Mac OS X, com uma nova versão da GUI Macintosh sobre o UNIX de Berkeley. E, em 2005, a Apple anunciou que estaria mudando para processadores Intel. Para concorrer com o Macintosh, a Microsoft inventou o Windows. Originalmente, o Windows era apenas um ambiente gráfi co sobre o MS-DOS de 16 bits (isto é, era mais um shell do que um verdadeiro sistema operacional). Entretanto, as versões atuais do Windows são descendentes do Windows NT, um sistema de 32 bits completo, reescrito desde o início. O outro concorrente importante no mundo dos computadores pessoais é o UNIX (e seus vários derivados). O UNIX é mais poderoso em estações de trabalho e em outros computadores topo de linha, como os servidores de rede. Ele é especialmente difundido em máquinas equipadas com chips RISC de alto desempenho. Em computadores baseados em Pentium, o Linux está se tornando uma alternativa popular ao Windows para os estu- dantes e, cada vez mais, para muitos usuários corporativos. (Neste livro, usaremos o termo “Pentium” para nos referirmos à família Pentium inteira, incluindo os microprocessadores Celeron, de baixo poder computacional e os Xeon, de mais alto poder computacional e seus compatíveis AMD). Embora muitos usuários de UNIX, especialmente programadores experientes, prefi - ram uma interface baseada em comandos a uma GUI, praticamente todos os sistemas UNIX suportam um sistema de janelas chamado X Window, desenvolvido no M.I.T. Esse sistema trata do gerenciamento básico de janelas, permitindo aos usuários criar, excluir, mover e re- dimensionar janelas usando um mouse. Freqüentemente, uma GUI completa, como a Motif, é disponibilizada para funcionar sobre o sistema X Window, proporcionando ao UNIX a apa- rência e o comportamento do Macintosh ou do Microsoft Windows para os usuários UNIX que assim o desejarem. Um desenvolvimento interessante, que começou durante meados dos anos 80, é o cres- cimento das redes de computadores pessoais executando sistemas operacionais de rede e sistemas operacionais distribuídos (Tanenbaum e Van Steen, 2002). Em um sistema opera- cional de rede, os usuários sabem da existência de vários computadores e podem se conectar a máquinas remotas e copiar arquivos de uma para outra. Cada máquina executa seu próprio 34 SISTEMAS OPERACIONAIS sistema operacional local e tem seu próprio usuário (ou usuários) local. Basicamente, as má- quinas são independentes entre si. Os sistemas operacionais de rede não são fundamentalmente diferentes dos sistemas operacionais locais a uma máquina. Obviamente, eles precisam de uma controladora de inter- face de rede e de algum software de baixo nível para fazê-los funcionar, assim como de pro- gramas para obter login remoto e acesso remoto aos arquivos, mas essas adições não mudam a estrutura básica do sistema operacional. Em contraste, um sistema operacional distribuído é aquele que aparece para seus usuá- rios como um sistema de um processador tradicional, mesmo sendo composto, na verdade, por vários processadores. Os usuários não devem saber onde seus programas estão sendo exe- cutados nem onde seus arquivos estão localizados; tudo isso deve ser manipulado automática e efi cientemente pelo sistema operacional. Os verdadeiros sistemas operacionais distribuídos exigem mais do que apenas adicionar um código em um sistema operacional centralizados, pois os sistemas distribuídos e os cen- tralizados diferem de maneiras importantes. Os sistemas distribuídos, por exemplo, freqüen- temente permitem que os aplicativos sejam executados em vários processadores ao mesmo tempo, exigindo assim algoritmos de escalonamento mais complexos para otimizar o volume de paralelismo. Muitas vezes, os atrasos de comunicação em rede signifi cam que esses algoritmos (e outros) devam ser executados com informações incompletas, desatualizadas ou mesmo incor- retas. Essa situação é radicalmente diferente de um sistema operacional centralizado, no qual se tem informações completas sobre o estado do sistema. 1.2.5 A história do MINIX 3 No início, o código-fonte do UNIX (versão 6) estava amplamente disponível, sob licença da AT&T, e era muito estudado. John Lions, da Universidade de New South Wales, na Austrália, escreveu um livro descrevendo seu funcionamento, linha por linha (Lions, 1996), e ele foi usado (com permissão da AT&T) como livro texto em muitos cursos universitários sobre sistemas operacionais. Quando a AT&T lançou a versão 7, começou a perceber que o UNIX era um produto comercial valioso e, assim, distribuiu essa versão com uma licença proibindo o estudo do código-fonte em cursos para evitar o risco de expor seu status de segredo comercial. Muitas universidades obedeceram simplesmente eliminando o estudo do UNIX e ensinando apenas a teoria. Infelizmente, ensinar apenas a teoria deixa o aluno com uma visão prejudicada do queum sistema operacional realmente é. Os assuntos teóricos normalmente abordados em deta- lhes em cursos e livros sobre sistemas operacionais, como os algoritmos de escalonamento, não têm tanta importância na prática. Os assuntos realmente importantes, como E/S e siste- mas de arquivos, geralmente são abandonados, pois há pouca teoria a respeito. Para corrigir essa situação, um dos autores deste livro (Tanenbaum) decidiu escrever um novo sistema operacional a partir de zero, que seria compatível com o UNIX do ponto de vista do usuário, mas completamente diferente por dentro. Por não usar sequer uma linha do código da AT&T, esse sistema evita as restrições de licenciamento; assim, ele pode ser usado para estudo individual ou em classe. Desse modo, os leitores podem disse- car um sistema operacional real para ver o que há por dentro, exatamente como os alunos de biologia dissecam rãs. Ele foi chamado de MINIX e foi lançado em 1987, com seu código-fonte completo para qualquer um estudar ou modifi car. O nome MINIX signifi ca mini-UNIX, pois ele é pequeno o bastante até para quem não é especialista poder entender seu funcionamento. CAPÍTULO 1 • INTRODUÇÃO 35 Além da vantagem de eliminar os problemas jurídicos, o MINIX tem outra vantagem em relação ao UNIX. Ele foi escrito uma década depois deste e foi estruturado de maneira mais modular. Por exemplo, desde a primeira versão do MINIX, o sistema de arquivos e o gerenciador de memória não fazem parte do sistema operacional, mas são executados como programas de usuário. Na versão atual (MINIX 3) essa modularização foi ampliada para os drivers de dispositivos de E/S, todos os quais (com exceção do driver de relógio) são exe- cutados como programas de usuário. Outra diferença é que o UNIX foi projetado para ser efi ciente; o MINIX foi projetado para ser legível (se é que alguém pode falar de qualquer programa com centenas de páginas como sendo legível). O código do MINIX, por exemplo, contém milhares de comentários. O MINIX foi originalmente projetado para ser compatível com o UNIX versão 7 (V7). A versão 7 foi usada como modelo devido a sua simplicidade e elegância. Às vezes, diz-se que a versão 7 foi um aprimoramento não apenas em relação a todas as versões antecedentes, mas também em relação a todas as suas sucessoras. Com o advento do POSIX, o MINIX começou a evoluir para o novo padrão, embora mantendo a compatibilidade com as versões anteriores dos programas existentes. Esse tipo de evolução é comum na indústria dos compu- tadores, pois qualquer fornecedor deseja introduzir um novo sistema sem provocar grandes transformações ou transtornos aos seus clientes atuais. A versão do MINIX descrita neste livro, MINIX 3, é baseada no padrão POSIX. Assim como o UNIX, o MINIX foi escrito na linguagem de programação C e destinado a ser facilmente portado para vários computadores. A implementação inicial foi para o IBM PC. Subseqüentemente, o MINIX foi portado para várias outras plataformas. Para manter a fi losofi a do “quanto menor, melhor”, originalmente, o MINIX nem mesmo exigia um disco rígido para funcionar (em meados dos anos 80, os discos rígidos ainda eram uma novidade cara). À medida que o MINIX foi crescendo em funcionalidade e tamanho, chegou um ponto em que foi necessário ter-se disco rígido, mas mantendo a fi losofi a “quanto menor, melhor”, uma partição de 200 MB é sufi ciente (contudo, para sistemas embarcados nenhum disco rígido é necessário). Em contraste, mesmo os sistemas Linux “enxutos” exigem 500 MB de espaço em disco e vários GB são necessários para instalar aplicativos comuns. Para o usuário médio sentado diante de um IBM PC, executar o MINIX é semelhante a executar o UNIX. Todos os programas básicos estão presentes, como cat, grep, ls, make e o shell, e executam as mesmas funções de seus equivalentes UNIX. Assim como o sistema operacional em si, todos esses programas utilitários foram completamente reescritos a partir de zero pelo autor, seus alunos e algumas outras pessoas dedicadas, sem nenhum código pa- tenteado da AT&T ou de outros. Agora existem muitos outros programas distribuídos gratui- tamente e, em muitos casos, têm sido portados (recompilados) com sucesso no MINIX. O MINIX continuou a ser desenvolvido por uma década e o MINIX 2 foi lançado em 1997, junto com a segunda edição deste livro, que descrevia a nova versão. As alterações feitas entre as versões 1 e 2 foram signifi cativas (por exemplo, do modo real de 16 bits em um 8088 usando disquetes, para o modo protegido de 32 bits em um 386 usando um disco rígido), mas evolutivas. O desenvolvimento continuou lento, mas sistematicamente, até 2004, quando Tanen- baum se convenceu de que o software estava fi cando grande demais e não confi ável, ten- do decidido melhorar novamente o segmento MINIX ligeiramente adormecido. Junto com seus alunos e programadores da Vrije Universiteit, em Amsterdã, ele produziu o MINIX 3, um reprojeto signifi cativo do sistema, reestruturando bastante o núcleo, reduzindo seu ta- manho e dando ênfase à modularidade e à confi abilidade. A nova versão se destinava tanto a PCs quanto a sistemas embarcados, onde a compacidade, modularidade e confi abilidade são fundamentais. Embora algumas pessoas do grupo pedissem um nome completamente novo, 36 SISTEMAS OPERACIONAIS fi nalmente fi cou decidido que ele se chamaria MINIX 3, pois o nome MINIX já era bem co- nhecido. Como uma analogia, quando a Apple abandonou seu próprio sistema operacional, o Mac OS 9, e o lançou como uma variante do UNIX da Berkeley, o nome escolhido foi Mac OS X, em vez de APPLIX ou algo assim. Mudanças fundamentais semelhantes ocorreram na família Windows e seu nome foi mantido. O núcleo do MINIX 3 tem bem menos de 4000 linhas de código executável, com- paradas às milhões de linhas de código executável do Windows, do Linux, do FreeBSD e de outros sistemas operacionais. Um núcleo pequeno é importante, pois erros de núcleo são bem mais devastadores do que erros em programas de modo usuário, e mais código signifi ca mais erros. Um estudo cuidadoso mostrou que o número de erros detectados por 1000 linhas de código executável varia de 6 a 16 (Basili e Perricone, 1984). O número real de erros provavelmente é muito mais alto, pois os pesquisadores só puderam contar erros relatados. Um outro estudo (Ostrand et al., 2004) mostrou que, mesmo depois de mais de uma dezena de lançamentos, em média 6% de todos os arquivos continha erros que foram relatados posteriormente e, após certo ponto, o nível de erros tende a estabilizar, em vez de tender assintoticamente a zero. Esse resultado é corroborado pelo fato de que, quando um verifi cador de modelo muito simples e automatizado foi posto em versões estáveis do Linux e do OpenBSD, ele descobriu centenas de erros de núcleo, esmagadoramente presentes em drivers de dispositivos (Chou et al., 2001; e Engler et al., 2001). Esse é o motivo pelo qual os drivers de dispositivos foram retirados do núcleo no MINIX 3; eles podem causar menos danos no modo usuário. Neste livro, o MINIX 3 será usado como exemplo. Entretanto, a maioria dos comentá- rios sobre as chamadas de sistema do MINIX 3 (em oposição aos comentários sobre o código em si), também se aplica aos outros sistemas UNIX. Esta observação deve ser lembrada ao se ler o texto. Algumas palavras sobre o Linux e seu relacionamento com o MINIX podem ser de interesse para alguns leitores. Logo depois que o MINIX foi lançado, foi formado um grupo de discussão na USENET, comp.os.minix, para discuti-lo. Dentro de poucas semanas o gru- po tinha 40.000 assinantes, a maioria dos quais querendo acrescentar um grande número de recursos novos no MINIX para torná-lo maior e melhor (bem, pelo menos maior). Todos os dias, centenas deles davam sugestões, idéias e, freqüentemente, forneciam trechos de código- fonte. O autor do MINIX conseguiu resistir a essa investida por vários anos, para manter o MINIX limpo o sufi ciente para os alunoso entenderem, e pequeno o bastante para que pudes- se ser executado nos computadores que eles podiam comprar. Para as pessoas que não tinham muita consideração com o MS-DOS, a existência do MINIX (com o código-fonte) como uma alternativa era mesmo um motivo para fi nalmente sair e comprar um PC. Uma dessas pessoas foi um estudante fi nlandês chamado Linus Torvalds. Torvalds ins- talou o MINIX em seu novo PC e estudou cuidadosamente o código-fonte. Ele queria ler os grupos de discussão da USENET (como o comp.os.minix) em seu próprio PC, em vez de usar o da universidade, mas faltavam no MINIX alguns recursos de que precisava; assim, ele escreveu um programa para fazer isso, mas logo descobriu que precisava de um driver de terminal diferente, de modo que também o escreveu. Em seguida, ele queria fazer download e salvar mensagens postadas; portanto, escreveu um driver de disco e depois um sistema de arquivos. Em agosto de 1991, ele tinha produzido um núcleo primitivo. Em 25 de agosto de 1991, ele o anunciou no comp.os.minix. Esse anúncio atraiu outras pessoas para ajudá-lo e, em 13 de março de 1994, foi lançado o Linux 1.0. Assim nasceu o Linux. O Linux se tornou um dos sucessos notáveis do movimento do código-fonte aberto (que o MINIX ajudou a iniciar). O Linux está superando o UNIX (e o Windows) em mui- tos ambientes, parcialmente porque agora se encontram disponíveis PCs comerciais que CAPÍTULO 1 • INTRODUÇÃO 37 suportam o Linux com desempenho equiparável a algumas implementações proprietárias de UNIX para sistemas RISC. Outros programas de software de código-fonte aberto, nota- damente o servidor web Apache e o banco de dados MySQL, funcionam bem com o Linux no mundo comercial. O Linux, o Apache, o MySQL e as linguagens de programação de código-fonte aberto Perl e PHP são freqüentemente usados em conjunto nos servidores web e às vezes são referidos pelo acrônimo LAMP. Para obter mais informações sobre a história do Linux e sobre software de código-fonte aberto, consulte DiBona et al. (1999), Moody (2001) e Naughton (2000). 1.3 CONCEITOS DE SISTEMA OPERACIONAL A interface entre o sistema operacional e os programas de usuário é defi nida pelo conjunto de “instruções estendidas” fornecidas pelo sistema operacional. Essas instruções estendidas são tradicionalmente conhecidas como chamadas de sistema. Para entendermos realmente o que os sistemas operacionais fazem, devemos examinar essa interface detidamente. As chamadas disponíveis na interface variam de um sistema operacional para outro (embora os conceitos subjacentes tendem a ser semelhantes). Assim, somos obrigados a fazer uma escolha entre (1) generalidades vagas (os “sistemas operacionais têm chamadas de sistema para ler arquivos”) e (2) algum sistema específi co (“o MINIX 3 tem uma chamada de sistema read com três parâmetros: um para especifi car o arqui- vo, um para dizer onde os dados devem ser transferidos e um para informar quantos bytes de- vem ser lidos”). Escolhemos a última abordagem. Ela é mais trabalhosa, mas oferece uma visão melhor do que os sistemas operacionais realmente fazem. Na Seção 1.4, veremos com detalhes as chamadas de sistema básicas presentes no UNIX (incluindo as diversas versões de BSD), no Linux e no MINIX 3. Para simplifi car, vamos nos referir apenas ao MINIX 3, mas as chamadas de sistema correspondentes do UNIX e do Linux são baseadas no POSIX, na maioria dos casos. Entretanto, antes de vermos as chamadas de sistema reais, é interessante ver um panorama do MINIX 3 para ter uma visão geral do que é um sistema operacional como um todo. Essa visão geral se aplica igualmente bem ao UNIX e ao Linux, conforme mencionado anteriormente. As chamadas de sistema do MINIX 3 dividem-se, grosso modo, em duas categorias amplas: aquelas que tratam com processos e aquelas que tratam com o sistema de arquivos. Examinaremos agora cada uma delas separadamente. 1.3.1 Processos Um conceito importante no MINIX 3, e em todos os sistemas operacionais, é o processo. Um processo é basicamente um programa em execução. Associado a cada processo está o espaço de endereçamento, uma lista de posições de memória a partir de um mínimo (normalmente, 0) até um máximo que o processo pode ler e escrever. O espaço de endereçamento contém o programa executável, os dados do programa e sua pilha. Também associado a cada processo está um con- junto de registradores, incluindo o contador de programa, o ponteiro da pilha e outros registrado- res de hardware e todas as outras informações necessárias para a execução do programa. Voltaremos ao conceito de processo com muito mais detalhes no Capítulo 2, mas, por enquanto, a maneira mais fácil de entender um processo intuitivamente é pensar nos sistemas de multiprogramação. Periodicamente, o sistema operacional decide interromper a execução de um processo e iniciar a execução de outro, por exemplo, porque o primeiro ultrapassou sua parcela de tempo da CPU no último segundo. Quando um processo é temporariamente suspenso, como esse, posteriormente ele deve ser reiniciado exatamente no mesmo estado em que estava quando foi interrompido. Isso DICA DO PROFESSOR Os sistemas operacionais passaram por uma grande evolução em poucas décadas. Os grandes mainframes presentes em empresas, laboratórios e faculdades tinham muito menos recursos e poder de processamento do que os atuais smartphones. Tudo isso foi possível em virtude de um conjunto de inovações, cada uma em seu período, que permitiram a resolução de um problema existente, por meio da mudança em relação ao que era feito. Um exemplo clássico é a substituição das válvulas pelos transitores, que garantiu maior durabilidade e confiança aos computadores. Nesta Dica do Professor, você irá acompanhar a evolução dos computadores e dos sistemas operacionais ao longo do tempo. Conteúdo interativo disponível na plataforma de ensino! EXERCÍCIOS 1) Os usuários utilizam diversos programas para a realização de suas tarefas no computador. Dependendo da atividade, o programa precisa ler uma entrada que o usuário digitou no teclado; contudo, a leitura do teclado não pode ser feita diretamente pelo programa, precisando comunicar-se com o sistema operacional. A intermediação do sistema operacional é necessária pelo seguinte motivo: A) O programa do usuário roda em modo núcleo e tem acesso à leitura do teclado, mas não sabe comunicar-se com o hardware do teclado. B) O programa do usuário roda em modo núcleo, porém não tem acesso à leitura do teclado e nem sabe comunicar-se com o hardware do teclado. C) O programa do usuário roda em modo usuário, não tem nenhuma permissão ou acesso a recursos, exceto por meio do sistema operacional. D) O programa do usuário roda em modo usuário e tem permissão para acessar diretamente a leitura do teclado, contudo fazer pelo sistema operacional é mais eficiente. E) O programa do usuário roda em modo usuário e precisa ser programado para acessar diretamente o hardware do teclado. 2) Em algumas tarefas, o programa precisa comunicar-se com o sistema operacional para utilização de algum recurso. Essa solicitação enviada pelo programa ao sistema operacional é chamada de: A) rotina de execução. B) chamada de sistema. C) bloqueio do programa. D) chamada de E/S. E) interrupção de programa. 3) Nos primeiros computadores, a programação era feita de modo mecânico, por meio de chaves e interruptores, para a inserção bit a bit dos programas. A criação das linguagens de montagem facilitou muito a programação, pois: A) permitiu que os computadores entendessem a linguagem natural. B) possibilitou usar comandos em linguagem de programação alto nível. C) reduziu a quantidade de bits para criar os programas. D) definiu comandos derivados do inglês que eram traduzidos para binário, permitindo o reaproveitamento. E) registrou comandos pré-prontos na memória do computador. 4) A multiprogramação foi uma técnica muito importante introduzida pelossistemas operacionais de terceira geração. Assinale a alternativa que mostra um exemplo de estratégia de multiprogramação apresentado pelos sistemas dessa geração: A) A execução paralela entre os vários núcleos do processador. B) A divisão da memória entre os programas e o sistema operacional simultaneamente. C) A implementação de threads em nível de usuário. D) A implementação de threads em nível de núcleo. E) A interrupção preemptiva do relógio. 5) Dentre as principais funcionalidades obtidas com a evolução dos sistemas operacionais, o compartilhamento de tempo entre diferentes usuários permite: A) acessar um recurso simultaneamente a outros processos. B) executar processos em paralelo. C) compartilhar a utilização da unidade de processamento entre os usuários ativos. D) a liberação de tempo para outros processos. E) o fatiamento do tempo de processamento para cada processo. NA PRÁTICA Cada vez mais os computadores estão presentes no dia a dia, e, consequentemente, os sistemas operacionais também. Em diversas tarefas que são executadas nos programas, raramente é possível perceber o importante papel do sistema operacional na comunicação do software como o hardware, facilitando as tarefas do usuários (pessoas e programas também). Neste Na Prática, você vai conhecer uma situação simples da utilização do sistema operacional na programação. Conteúdo interativo disponível na plataforma de ensino! SAIBA MAIS Para ampliar o seu conhecimento a respeito desse assunto, veja abaixo as sugestões do professor: Conceitos de sistemas operacionais Nesta videoaula da Univesp TV você poderá rever e complementar o conteúdo quanto à definição de um sistema operacional, como ele funciona e sua evolução histórica. Conteúdo interativo disponível na plataforma de ensino! A história dos sistemas operacionais Neste artigo você poderá conhecer um pouco mais em detalhes a evolução dos sistemas operacionais até os dias de hoje. Conteúdo interativo disponível na plataforma de ensino! O que é Linux e qual a sua história? Neste artigo você poderá conhecer mais sobre os sistemas operacionais baseados em Linux e um pouco da sua história. Conteúdo interativo disponível na plataforma de ensino!
Compartilhar