Nesta seção, vamos discutir os problemas enfrentados durante o projeto c implementação de um sistema. Evidentemente, não existem soluções completas para os problemas de projeto, mas algumas abordagens têm sido bem-sucedidas.
56 • Sistemas Operacionais
3.8.1 Objetivos do projeto
O primeiro problema no projeto de um sistema é definir os seus objetivos e especificações. No nível mais alto, 0 projeto do sistema será afetado pela escolha de hardware e o tipo de sistema: batch, tempo compartilhado, monousuário, multiusuário, distribuído, tempo real ou de uso geral.
Além desse nível de projeto mais alto, os requisitos podem ser muito mais difíceis de especificar. Os re- quisitos podem ser divididos em dois grupos básicos: objetivos de usuário e objetivos do sistema.
Os usuários desejam certas propriedades óbvias em um sistema: ele deve ser conveniente e fácil de usar, fácil de aprender, confiável, seguro e rápido. E claro que essas especificações não são particularmente úteis no projeto do sistema, pois não há concordância geral quanto a como alcançar esses objetivos.
Um conjunto semelhante de requisitos pode ser definido pelas pessoas q u e devem projetar, criar, manter e operar o sistema: o sistema operacional deve ser fácil de projetar, implementar e manter; deve ser flexível, confiável, livre de erros e eficiente. Mais uma vez, os requisitos são vagos e nào têm uma solução geral.
Não existe uma solução única para o problema de definir os requisitos de um sistema operacional. A grande gama de sistemas mostra que diferentes requisitos podem resultar em uma grande variedade de solu- ções para ambientes diferentes. Por exemplo, os requisitos para MS-DOS, um sistema monousuário para mi- crocomputadores, devem ter sido substancialmente diferentes dos requisitos para o MVS, o grande sistema operacional multiusuário com acesso múltiplo para mainframes IBM.
A especificação e o projeto de um sistema operacional são tarefas altamente criativas. Embora nenhum li- vro didático ensine como fazê-lo, existem princípios gerais, desenvolvidos pela área de engenharia de soft- ware, que se aplicam especificamente a sistemas operacionais.
3.8.2 Mecanismos e políticas
Um princípio importante é a separação entre política c mecanismo. Os mecanismos determinam como faier alguma coisa-, as políticas determinam o que será feito. Por exemplo, o timer (consulte a Seção 2.5) é um me- canismo para garantir a proteção da CPU, mas decidir durante quanto tempo o timer deverá ser configurado para determinado usuário é uma decisão que envolve políticas.
A separação entre política e mecanismo é importante para fins de flexibilidade. As políticas tendem a mu- dar em diferentes locais ou com o tempo. Na pior das hipóteses, cada mudança na política exigiria uma mu- dança no mecanismo subjacente. Um mecanismo geral seria mais desejável. Com isso a mudança na política exigiria a redefinição de apenas certos parâmetros do sistema. Por exemplo, se, em um sistema de computa- ção, uma política determinar que programas com uso intensivo de I/O devem ter prioridade sobre aqueles com uso intensivo de CPU, a política oposta poderia ser facilmente instituída em algum o u t r o sistema de computação se o mecanismo fosse adequadamente separado e independente da política.
Os sistemas operacionais baseados em microkernel levam a separação entre mecanismo e política ao ex- tremo, implementando um conjunto básico de blocos de construção primitivos. Esses blocos são praticamen- te independentes de política, permitindo o acréscimo de mecanismos c políticas mais avançados através de módulos do kernel criados pelo usuário ou através de programas de usuário. No o u t r o extremo está um siste- ma como o sistema operacional Apple Macintosh, no qual mecanismos e políticas são codificados no sistema para dar a ele aparência e comportamento globais. Todas as aplicações têm interfaces semelhantes, porque a própria interface é incorporada ao kernel.
As decisões baseadas em políticas são importantes para todos os problemas de alocação de recursos e de escalonamento. Sempre que for necessário decidir se determinado recurso deve ou não ser alocado, uma de- cisão baseada em política deve ser tomada. Sempre que a questão envolver como em vez de o quê, um meca- nismo deve ser determinado.
3.8.3 Implementação
Depois que o sistema operacional é projetado, ele deve ser implementado. Tradicionalmente, os sistemas operacionais têm sido escritos em linguagem assembiy. Agora, no entanto, geralmente são escritos em lingua- gens de nível mais alto. Por exemplo, uma implementação da J V M foi escrita cm Java na Sun Microsystems.
Estruturas de Sistemas Operacionais • 57 O primeiro sistema que não foi escrito em linguagem assembly provavelmente foi o Master Control Pro- gram (MCP) para computadores Burroughs. MCP foi escrito em uma variante de ALGOL. O MULTICS, de- senvolvido no MIT, foi escrito basicamente cm PL/1. O sistema operacional Primos para computadores Pri- me foi escrito cm um dialcto de Fortran. Os sistemas operacionais UNIX, OS/2 e Windows NT são basicamente escritos em linguagem C. Apenas 900 linhas do código do UNIX original foram escritas em lin- guagem assembly, boa parte sendo do escalonador e dos drivers de dispositivo.
As vantagens de usar uma linguagem de alto nível, ou pelo menos uma linguagem de implementação de sistemas, para implementar sistemas operacionais são as mesmas obtidas quando a linguagem é usada para programas aplicativos: o código pode ser escrito de forma mais rápida, é mais compacto c mais fácil de enten- der e depurar. Alem disso, melhorias na tecnologia de compiladores aperfeiçoarão o código gerado para todo o sfstema operacional por simples recompilação. Finalmente, é muito mais fácil portar o sistema operacional -movê-lo para algum outro h a r d w a r e - s e ele estiver escrito em uma linguagem de alto nível. Por exemplo, o MS-DOS foi escrito na linguagem assembly Intel 8088. Consequentemente, está disponível apenas na família Intel de CPUs. O sistema operacional UNIX, por outro lado, que foi escrito basicamente em C, está disponí- vel em várias CPUs diferentes, incluindo Intel 80X86, Motorola 680X0, SPARC c MIPS RX000.
As principais desvantagens da implementação de um sistema operacional em uma linguagem de nível mais alto são velocidade reduzida e maiores requisitos de armazenamento. Embora um programador espe- cialista em linguagem assembly possa gerar pequenas rotinas eficientes, para programas grandes os compila- dores modernos podem efetuar análises complexas e aplicar otimizações sofisticadas que geram código exce- lente. Os processadores modernos têm múltiplas unidades funcionais e pipelining massivo, podendo lidar com dependências complexas que podem superar a limitada capacidade humana de controlar detalhes.
Como acontece em outros sistemas, importantes melhorias de desempenho nos sistemas operacio- nais tendem a ser resultado de melhores estruturas de dados e algoritmos do que de excelente código cm linguagem assembly. Além disso, embora os sistemas operacionais sejam grandes, apenas uma pequena quantidade de código é crítica ao alto desempenho; o gerenciador de memória e o escalonador de CPU são provavelmente as rotinas mais críticas. Depois que o sistema tiver sido escrito e estiver funcionando corretamente, rotinas que representem gargalos podem ser identificadas c substituídas por equivalentes em linguagem assembly.
Para identificar gargalos, é preciso monitorar o desempenho do sistema. Código deve ser acrescentado para calcular e exibir medidas do comportamento do sistema. Em vários sistemas, o sistema operacional rea- liza essa tarefa produzindo listagens do comportamento do sistema. Todos os eventos interessantes são regis- trados com a respectiva hora e parâmetros importantes, sendo gravados cm um arquivo. Mais tarde, um pro- grama de análise pode processar o arquivo de log para determinar o desempenho do sistema e identificar gargalos c ineficiências. Esses mesmos registros de log podem ser fornecidos como entrada para uma simula- ção de um sistema melhorado sugerido. Os registros de log também podem ajudar as pessoas a encontrar er- ros no comportamento de um sistema operacional.
Uma alternativa é calcular e exibir medidas de desempenho em tempo real Por exemplo, um timer pode acionar uma rotina para armazenar o valor corrente do ponteiro de instruções. O resultado é um quadro es- tatístico das posições mais frequentemente usadas no programa. Essa abordagem pode permitir que os ope- radores do sistema fiquem familiarizados com o comportamento do sistema e modifiquem a operação do sis- tema cm tempo real.