Detalhes

Categoria: Sistemas Operacionais

Atualização: Quinta, 03 Abril 2008 14:52

Autor: vovó Vicki

Acessos: 40130

MÓDULO 10 do SO Numaboa

Agora que produzimos o pequeno SO NumaBoa, está na hora de parar de brincar e começar a por um pouco de ordem na casa. Se não fizermos isto, com certeza vamos acabar perdendo o rumo. Não se esqueça de que SOs podem ser (e geralmente são) muito complexos...

Além de todos os aspectos relacionados a sistemas operacionais, ainda existe um caminhão de expressões e acrônimos que dão nó na cabeça de qualquer um. Acontece que a terminologia tem sua história, que coincide com a história dos próprios computadores. Neste módulo (e seguintes) seguiremos o rastro da história para explicar alguns termos e conceituar os sistemas operacionais.

Como você definiria um SO? Consegui encontrar duas "definições" interessantes: o Princípio dos Recursos e o Princípio da Estética. Este texto foi baseado numa parte do primeiro capítulo do livro An Operating Systems Vade Mecum, do professor da University of Wisconsin at Madison, Raphael A. Finkel, 1988, Prentice Hall, ISBN 0-13-637950-8. O livro pode ser antigo, mas os conceitos não. Então, vamos lá!

O Princípio dos Recursos

De acordo com o Princípio dos Recursos, considera-se que um

Um recurso é uma conveniência necessária para se realizar trabalho. O harware do computador fornece vários recursos fundamentais. Programas que realizam trabalhos precisam residir na memória, executar instruções e precisam de meios para aceitar dados e apresentar resultados. Estas necessidades estão relacionadas aos recursos fundamentais de espaço, tempo e transposição (entrada/saída). Um sistema operacional adiciona recursos a esses recursos fundamentais, por exemplo, arquivos que podem armazenar dados. Além disso, programas diferentes podem se comunicar através de portas que os conectem. É interessante notar que recursos de níveis mais altos podem ser construídos sobre os básicos.

A noção de processo é vital nos sistemas operacionais, mas é bastante difícil definir o que é um processo. Digamos que um processo é a execução de um programa, é uma entidade fundamental que necessita de recursos para poder realizar sua tarefa de executar o programa até o final. Imagine vários atores se apresentando num picadeiro de circo, cada um deles precisando de recursos próprios. Quando precisam de recursos, acionam o administrador de recursos (o distribuidor de recursos do sistema operacional). A função do administrador, para atender os atores, é fornecer os recursos necessários para cada ator e distribuí-los da forma mais justa possível. A função do administrador, para atender o público (que, afinal de contas, pagou entrada), é garantir que o máximo de recursos sejam usados e conseguir terminar o máximo de apresentações (processos) possíveis.

Outra forma de encarar os processos é considerá-los como agentes que representam os interesses dos usuários. Quando o usuário quiser escrever uma carta, um processo roda o programa que modifica um documento de acordo com as teclas digitadas; quando quiser enviar um e-mail, um processo (provavelmente um novo) roda um programa diferente que sabe como enviar documentos para caixas postais. Em geral, os processos rodam programas que ajudam o usuário. Para poder executar seu trabalho, os processos podem precisar da ajuda do sistema operacional em operações como reconhecer teclas digitadas ou colocando dados em áreas de armazenamento de longo prazo. Necessitam de recursos como espaço de memória e ciclos de máquina. O Princípio dos Recursos diz que o sistema operacional é o responsável pela disponibilização destes recursos.

Desenvolvimento histórico

Os sistemas operacionais evoluíram com o aumento da necessidade de tecnologia. Os primeiros computadores eram enormes, extremamente caros e muito difíceis de serem operados.

Open Shop

Indivíduos (chamados de usuários) contratavam horas nas quais podiam "mexer" num computador. As máquinas possuíam dois componentes principais: os dispositivos de transposição (entrada/saída) e a capacidade de executar um programa. Uma sessão típica no IBM 1620, computador usado ao redor de 1964, envolvia várias etapas na compilação e execução de um programa. Primeiro, o usuário carregava a primeira passada no compilador Fortran. Esta operação envolvia a limpeza da memória (digitando-se instruções estranhíssimas no console de teclado), a preparação do compilador (colocando uma pilha de uns 30 cm de cartões perfurados no leitor de cartões), depois a colocação do programa a ser compilado (outra pilha de cartões perfurados no leitor de cartões) e finalmente o acionamento do botão "load" (carregar) do leitor. O resultado era um novo conjunto de cartões perfurados chamado de "saída intermediária". Se ocorressem erros de compilação, uma luz ficava piscando no console e mensagens de erro apareciam no console de teclado. Se tudo corresse bem, o próximo passo era como o primeiro: carregar a segunda passada no compilador Fortran e colocar os cartões intermediários no leitor de cartões. Caso não ocorressem erros, esta operação gerava um segundo conjunto de cartões perfurados, o "jogo executável". A terceira etapa consistia em misturar um pouco o jogo executável de cartões, carregá-lo juntamente com uma biblioteca de subrotinas enorme (mais uns 30 cm de cartões) e observar o programa ser executado.

A saída de um programa podia ser em cartões ou em papel e, com frequência, a saída estava errada. Para descobrir porque, era preciso conferir (debugar) o programa, o que muitas vezes era feito alterando-se manualmente o conteúdo da memória ou até mesmo fazendo remendos (patches) no programa através de interruptores do console. Se o tempo contratado estivesse terminando, o usuário frustrado podia imprimir uma listagem da memória (conhecida como dump de memória) para depois tentar decifrá-la. Se o usuário terminasse antes do tempo contratado, a máquina ficava ociosa até completar o tempo.

Shop executado por operador

Devido ao custo da computação, cada minuto de máquina parada era uma verdadeira fortuna. Num esforço para evitar esta ociosidade, foram contratados operadores para realizar as tarefas repetitivas de montar pilhas de cartões ou preparar fitas magnéticas. Geralmente os operadores eram muito mais rápidos que os usuários comuns, diminuindo o tempo gasto na preparação das etapas de trabalho. Se o programa falhasse, o operador fazia um dump e o entregava ao solicitante - os usuários não podiam mais debugar diretamente. Além disso, dependendo do número de solicitações, o operador podia realizar tarefas em lotes como, por exemplo, fazer a primeira passada de várias tarefas no compilador Fortran, guardar todas as saídas intermediárias e depois fazer a segunda passada numa tacada só. Com isto, diminuía-se ainda mais o tempo ocioso.

Outro aspecto importante era a priorização de tarefas visando a otimização do trabalho, onde trabalhos muito demorados podiam ser deixados para o turno da noite.

Transposição offline

Muitas das tarefas realizadas pelo operador eram repetitivas. O estágio seguinte do desenvolvimento foi automatizar estas tarefas. Em primeiro lugar, as tarefas de entrada passaram a ser realizadas offline usando-se computadores separados, algumas vezes chamados de "satélites", cuja única tarefa era transferir cartões para fitas magnéticas. Quando uma fita estivesse completa, o operador a transferia para o computador principal. A leitura da fita era mais rápida do que a dos cartões, ganhando-se tempo na transposição (entrada). Da mesma forma, as saídas também eram geradas em fita, processo muito mais rápido do que perfurar cartões. A fita de saída era depois convertida numa listagem através de uma impressora offline.

Um pequeno programa monitor residente, que permanecia na memória enquanto as tarefas eram executadas, reinicializava a máquina após cada uma das tarefas completadas e carregava a próxima. Foram estabelecidas convenções para os cartões (ou "imagem de cartões" quando estavam em fita) para separar tarefas e especificar suas necessidades. Estas convenções foram os rudimentos das linguagens de comando. Por exemplo, uma das convenções era colocar um asterisco na primeira coluna dos cartões de controle para diferenciá-los dos cartões de dados.

O monitor residente tinha várias atribuições: interpretar a linguagem de comando, realizar uma contabilidade rudimentar e fornecer entradas e saídas independentes de dispositivos substituindo fitas por cartões. O programa executado podia lidar diretamente com fitas mas, como facilidade, o monitor residente fornecia algumas subrotinas para a leitura da fita de entrada e para a escrita da fita de saída.

Sistemas de spooling

O passo seguinte da evolução foi que as unidades de transposição (entrada/saída) trabalhassem simultaneamente com o computador. Elas geravam uma pedido de interrupção quando terminavam a leitura ou a escrita de um registro ao invés de ficarem sendo monitoradas o tempo todo. Uma interrupção fazia com que o computador armazenasse algumas informações críticas e que desviasse o processamento para uma localização específica, própria para o tipo da interrupção. Rotinas de serviços de dispositivos, conhecidas como drivers de dispositivo (condutores de dispositivos), foram adicionadas ao monitor residente para lidar com estas interrupções.

Foram adicionados discos como meio de armazenamento secundário. A partir daí o computador podia realizar um trabalho de computação enquanto lia outro do disco e imprimia os resultados de um terceiro a partir do disco. Diferentemente da fita, o disco permitia que os programas fossem armazenados em qualquer parte, de modo que o computador não precisava mais realizar as tarefas respeitando a ordem de entrada das mesmas. Um planejador (scheduler) primitivo foi adicionado ao monitor residente para organizar as tarefas de acordo com a prioridade e o tempo requerido para realizá-las. Estes critérios podiam ser especificados em cartões de controle. Apesar destas inovações, os operadores ainda eram necessários: montavam fitas de dados, tomavam decisões de prioridade de tarefas e reiniciavam o monitor residente quando este falhava ou era destruído inadvertidamente por alguma tarefa.

Este modo de operação ficou conhecido como sistema de spooling e seu monitor residente foi o avô dos modernos sistemas operacionais. A palavra spool, cuja tradução é bobina, carretel, na verdade foi derivada de Simultaneous Peripheral Operations On Line mas, na prática, é mais fácil imaginar um carretel de linha que corresponde às tarefas enroladas. Um dos primeiros sistemas de spooling foi o HASP (Houston Automatic Spooling Program), um adicional ao OS/360 para a família de computadores IBM 360.

Multiprogramação em lote

Os sistemas de spooling não usavam todos os seus recursos com eficiência: a tarefa que estivesse sendo executada não ocupava toda a área de memória e uma tarefa de transposição (entrada/saída) paralisava o computador até que fosse terminada. A evolução seguinte foi a introdução da multiprogramação, um esquema que permitia a ativação simultânea de várias tarefas - enquanto uma tarefa estivesse esperando uma operação de transposição ser completada, outra continuaria computando. Quanto mais tarefas fossem executadas simultaneamente, melhor. Entretanto, uma tarefa dependente de computação (uma que realizava pouca transposição mas muita computação) poderia facilmente paralisar tarefas dependentes de transposição. Havia uma competição pelo recurso tempo.

A multiprogramação também introduziu a competição pelo espaço. O número de tarefas que podiam ser acomodadas simultaneamente dependia da memória e do hardware disponível para dividir este espaço. Além disso, as tarefas precisavam ser protegidas contra a interferência inadvertida ou maliciosa de outras tarefas e uma tarefa não poderia ser inspecionada por outras. A atuação do monitor residente também se tornou mais crítica: se fosse destruído, ao invés de uma tarefa, várias delas seriam paralisadas.

Este tipo de multiprogramação é frequentemente denominado de multiprogramação em lote (batch) porque as tarefas combinam um conjunto de etapas. A primeira poderia ser constituída pelas compilações, a segunda poderia ser uma etapa de combinação (linking) para agrupar todas as peças compiladas num único programa e, finalmente, o programa seria executado. Se uma das compilações desse erro, não era necessário recompilar todas as tarefas, apenas a defeituosa.

Como cada etapa era relativamente independente, cada uma delas precisava do monitor residente. Suas tarefas eram individualizadas e suas necessidades de tempo, espaço e transposição eram atendidas. Aliás, duas etapas diferentes da mesma tarefa até poderiam ser realizadas ao mesmo tempo! O termo processo foi introduzido com o significado de entidade que realiza uma etapa de trabalho. O planejador criava um novo processo para cada etapa de trabalho e o processo terminava quando a etapa era completada. O sistema operacional, como será chamado o monitor residente daqui para frente, controlava cada processo e suas necessidades. Um processo podia solicitar ajuda ao kernel enviando uma chamada de serviço através da interface do processo. Os programas em execução não podiam mais controlar dispositivos diretamente porque poderiam causar conflitos e interferir no trabalho do kernel.

Agora os processos precisavam usar chamadas de serviço para acessar os dispositivos e o kernel tinha o controle total sobre a interface dos dispositivos. Atribuir recursos a processos não era uma tarefa trivial. Um processo poderia necessitar de recursos (como drives de fita) em vários estágios da sua execução. Se um recurso não estivesse disponível, o planejador poderia bloquear o processo por algum tempo, mas não indefinidamente.

A multiprogramação em lotes gerou novas idéias para a estruturação de sistemas operacionais. O kernel do sistema operacional passa a ser composto por rotinas que administram a memória, o tempo, os dispositivos e outros recursos. Ele passa a responder tanto a requisições de processos quanto a solicitações de interrupções de dispositivos. Além disto, também foram criados mecanismos para gerenciar solicitações concorrentes. Agora, o computador fica ocioso apenas quando não houver um processo pronto para rodar e nenhum dispositivo precisar de atenção.

Multiprogramação interativa

Mas ainda havia muito para ser melhorado e o próximo passo foi a multiprogramação interativa. O principal dispositivo de transposição orientado ao usuário mudou de cartões ou fitas para um terminal interativo. Ao invés de "empacotar" todos os dados que um programa necessitava para começar a rodar, o usuário interativo passou a fornecer as entradas necessárias para o seu funcionamento.

A computação interativa causou uma verdadeira revolução na forma como os computadores eram utilizados. Ao invés de serem tratados como trituradores de números, passaram a ser encarados como manipuladores de informações. Editores de texto interativos possibilitaram a construção de arquivos de dados online. Estes arquivos podiam ser programas, documentos ou dados. Ao invés de lidar com tarefas compostas por etapas, a multiprogramação interativa, também chamada de tempo compartilhado (timesharing), passou a lidar com sessões que duravam desde uma conexão incial (logon) até quando esta conexão era interrompida (logoff).

Durante o logon, o usuário fornecia dois tipos de identificação: um nome e uma senha. Estes dados eram convertidos num identificador de usuário, associado a todos os processos rodados e a todos os arquivos criados por este usuário. Este identificador ajudava o kernel a decidir de quem cobrar os serviços e se poderia permitir determinadas ações (como modificar arquivos, por exemplo).

Durante uma sessão, o usuário tinha a impressão de que os todos os recursos do computador estavam à disposição do seu terminal, mesmo quando mais de uma sessão estivesse ativa. Tipicamente, no momento do logon, um processo era criado para servir o usuário. Este primeiro processo, de acordo com a necessidade, poderia iniciar outros que eram necessários para completar etapas individuais. Este processo principal é chamado de interpretador de comandos.

Foi neste ponto que se tornou possível a introdução dos computadores pessoais. Os sistemas operacionais destas máquinas geralmente oferecem a interação, mas não a multiprogramação. O CP/M e o DOS são bons exemplos. Outros sistemas mais atuais já oferecem ambos (Windows NT, XP, 2000 e Linux).

Processamento distribuído

O que existe de mais atual em sistemas operacionais é o chamado processamento distribuído (ou computação distribuída), no qual computadores podem ser conectados através de uma grande variedade de dispositivos. O espectro vai desde computadores intimamente conectados, compartilhando a área de memória, até computadores ligados frouxamente, onde várias máquinas pertencentes a uma mesma rede internacional podem enviar e receber mensagens.

O Princípio da Estética

Tão importante quanto o Princípio dos Recursos, o Princípio da Estética define um sistema operacional como sendo:

Esconder os detalhes do hardware tem dois objetivos:

• SEGURANÇA. Vimos que o sistema operacional precisa evitar a interferência acidental ou maliciosa nele mesmo e em outros processos. Certas instruções de máquina, principalmente as que paralisam a máquina e as que ocasionam transposições, precisam ser tiradas do alcance dos processos. O hardware moderno disponibiliza vários estados de processador que restringem o uso de instruções. Por exemplo, algumas arquiteturas fornecem dois estados, chamados de estado privilegiado e estado não privilegiado. Os processos rodam no estado não privilegiado. Instruções, como as que realizam transposições e as que mudam o estado do processador, criam armadilhas quando executadas no estado não privilegiado. Estas armadilhas forçam o processador a saltar para o sistema operacional e a entrar no estado privilegiado. O sistema operacional roda no estado privilegiado mas pode restringir o acesso à memória principal de modo que os processos não possam acessar livremente toda a área.
• ABSTRAÇÃO. Sistemas operacionais, assim como outros componentes de software, constroem recursos de nível mais alto (virtuais) a partir de recursos de nível mais baixo (físicos). Os detalhes das estruturas de baixo nível são escondidas e estruturas de nível mais alto são introduzidas. Do ponto de vista de um processo, a máquina física é realçada pelo sistema operacional numa máquina virtual. O realce inclui simplicidade (escondendo detalhes) e funcionalidade (introduzindo novas estruturas). O tempo (possibilidade de execução) e o espaço (memória) não parecem estar sendo compartilhados entre diversos processos, portanto a máquina virtual parece ser mais simples do que a máquina física. A interface dos processos fornece instruções adicionais que melhoram o conjunto de instruções básicas do hardware, principalmente em se tratando de transposições. A máquina virtual, portanto, é mais funcional que a máquina física.
  Do ponto de vista do usuário, o sistema operacional fornece serviços que não existem na máquina subjacente. Estes serviços incluem carregar e rodar programas, rodar vários programas simultaneamente, armazenamento de dados e programas e ser incluído em redes de computadores.

Um exemplo importante do papel da estética no sistema operacional é encontrado em serviços de transposição. Dispositivos de transposição são muito difíceis de serem programados eficiente e corretamente. A maioria dos sistemas operacionais fornecem drivers de dispositivo que realizam operações de transposição para atender processos. Estes drivers também garantem que dois processos não tentem acidentalmente usar o mesmo dispositivo num dado momento. As operações fornecidas geralmente se encontram num nível muito mais alto do que as fornecidas pelo próprio dispositivo. Por exemplo, as interrupções de tarefa terminada podem ficar escondidas e/ou o sistema operacional pode bloquear processos que realizem transposições enquanto outra transposição estiver ocorrendo.

Considerações finais

Nada como trilhar o caminho já trilhado por outros. É mais fácil e o aprendizado é mais rápido. Você está achando que é muita teoria e pouco resultado prático? Pois então fique sabendo que, para projetar um sistema operacional, se não tivermos uma idéia muito clara dos elementos envolvidos e se não planejarmos cuidadosamente cada etapa do processo, a chance de sucesso é mínima. Lembre-se de que um sistema operacional é como a espinha dorsal de uma máquina... qualquer desvio, e ela não vai andar direito