MINIX: Gerenciamento de Processos e Memória

Transcrição

1 MINIX: Gerenciamento de Processos e Memória Elaine Alves 1, Rafael T. Rondão 1, Vinicius A. Zanquini 1 1 Grupo MINIX de Sistemas Operacionais (SO), Universidade Federal do ABC Resumo Princípios de controle de processos e intercomunicação, e gerencia de memória aplicados ao sistema operacional MINIX. Palavras-chave: MINIX 3, Gerenciamento de Processos, Gerenciamento de Memória. Introdução Este artigo tem por objetivo discorrer sobre gerenciamento de memória e de processos por Sistemas Operacionais, fazendo isto por meio de um estudo de caso do Sistema Operacional MINIX, desenvolvido por Andrew S. Tanenbaum, e descrito amplamente em [1]. De acordo com Tanenbaum[1], o Sistema Operacional pode ser definido como (1) uma extensão da arquitetura, e (2) um gerenciador de recursos. Segue uma breve análise dos dois pontos de vista: SO como extensão da arquitetura: Tanenbaum afirma que programar a nível de máquina é muito difícil, especialmente ao realizar I/O. Programadores não gostariam de ter que escrever programas específicos para o hardware onde estão trabalhando, nem gostariam de ter que lidar com código extremamente maçante e complicado para realizar tarefas simples. A visão de SO como extensão da arquitetura enxerga o SO justamente como um facilitador do relacionamento entre o usuário do computador e o hardware. Por prover uma abstração de mais alto nível, o usuário de computador não precisa mais se preocupar, por exemplo, com o estado de rotação do motor do disco rígido, ou se a frequência usada para gravação deve ser modulada. Basta que enxergue o disco como uma coleção de arquivos nomeados, por exemplo. Detalhes da arquitetura física não devem ser apresentados ao usuário. Em resumo, nesta visão, a função do SO é apresentar ao usuário uma interface mais amigável e fácil de programar do que o hardware que está por baixo dele. SO como gerenciador de recursos: A outra visão afirma que o computador é um sistema complexo de recursos compartilhados por centenas de programas (em sistemas multiprogramáveis, ao mesmo tempo). Seria o caos se os programas tivessem controle absoluto sobre os recursos, alocando-os e desalocando-os conforme desejam. O SO tem por função, segundo esta visão, gerenciar estes recursos para que cada aplicação receba uma fração justa dos recursos. Tanenbaum afirma que podem existir dois tipos de divisão de recurso (ou multiplexação, conforme nomeado em [1]): no espaço, e no tempo. Multiplexação no tempo implica em ordenar a execução dos programas de modo que se alternem para obter acesso ao mesmo recurso. Exemplos claros disso são o uso de CPU (assumindo só um núcleo), onde dois processos não podem rodar ao mesmo tempo, e impressoras (dois usuários não podem imprimir documentos diferentes simultaneamente). Multiplexação no espaço é dividir o recurso para que cada usuário tenha uma fração ao mesmo tempo. Um claro é o gerenciamento de memória, onde vários programas são armazenados simultaneamente, para concorrerem por tempo de execução na CPU. A visão de SO como gerenciador de recursos será a mais útil para este artigo, onde se discorrerá sobre a gerência de processos e de memória no MINIX. Serão abordados, dentre outros, temas como a modularização do Kernel do MINIX e em quais camadas ocorrem o gerenciamente e criação de processos, os algoritmos de escalonamento e como a informação se organiza na memória, e os algoritmos de escalonamento de processos na CPU.

2 Metodologia Histórico Após o lançamento do UNIX(versão 7) licenciado com proibições de uso do código fonte pra estudos, Andrew S. Tanenbaum decidiu escrever um novo sistema operacional a partir do zero, mas que era compatível com o UNIX no modo usuário mas que internamente seria completamente diferente e sua licença aberta para estudos, esse sistema foi chamado de MINIX (mini-unix) e lançado em A segunda versão MINIX 2 foi lançada em Em 2004, após achar que o MINIX 2 estava aumentando suas linhas de código e ficando menos confiável, seu criador Tanenbaum resolveu reformular a estrutura do kernel reduzindo seu tamanho e colocando em primeiro lugar a modularidade e a confiabilidade. A diferença das versões 1 e 2 para a versão 3 é que as versões 1 e 2 foram projetadas para estudos, e a versão 3 é usada em computadores com recursos limitados e para aplicações que requeiram alta confiabilidade. Ao estudar o código do MINIX, Linus Torvalds achou que o Sistema Operacional necessitava de alguns melhoramentos. Torvalds criou em 1994, com a ajuda de outras pessoas, o kernel Linux 1.0, que evoluiu nas várias distribuições Linux que temos hoje. Gerenciamento de Processos O MINIX 3 é uma coleção de processos que se comunicam entre si, e também com os processos de usuários através de primitivas de passagem de mensagem. Deste modo, torna o sistema mais modular e de estrutura mais flexível. O MINIX 3 é estruturado em quatro camadas, cada uma com funções específicas. As quatro camadas são ilustradas na figura 1. Figura 1 Estrutura do MINIX O Kernel presente na última camada é o responsável pelo controle dos processos entre os estados executando, pronto e bloqueado. Ele também controla todas as trocas de mensagens entre processos. O Clock Task realiza o controle de sinais gerados pelo hardware. Esta camada 1 prove os privilégios para realizar chamadas de sistemas (system call) entre as camadas superiores. É a única com privilégios de modo supervisor. As chamadas de sistemas são implementadas pelo System Task. As três camadas superiores são, fundamentalmente, tratadas igualmente pelo Kernel. Todas limitadas a instruções modo usuário. A diferença está nos privilégios de cada camada. A camada 2 pode realizar algumas chamadas de sistema as quais as camadas 3 e 4 não podem. O mesmo pode ser dito para a camada 3. Enquanto a camada 4 não possui nenhum privilégio especial. Os processos no MINIX 3 seguem um modelo padrão de processo. Estes podem criar subprocessos, que por sua vez, podem criar outros subprocessos. Cria-se, assim, uma árvore de processos. De fato, todos os processos de usuários formam uma única árvore, contendo o processo Init como raiz. Os processos abaixo da camada 3 possuem um tratamento especial, visto que precisam ser iniciados antes de qualquer processo usuário. Durante a inicialização do MINIX 3, este procura hierarquicamente um dispositivo de boot, inicialmente disquete, CD-ROM e discos rígidos. Em discos rígidos, o primeiro setor conterá um pequeno programa e a tabela de partição. Este programa será carregado na memória, juntamente com a tabela, e será executado, encontrando a partição ativa. Esta partição contém o programa bootstrap no seu primeiro setor, que possui a finalidade de carregar o programa boot, que iniciará o sistema. Durante sua inicialização, o programa boot que irá realizar a comunicação com os dispositivos, visto que os processos encarregados para isso ainda não foram carregados. Os processos do sistema são carregados da camada mais inferior para as superiores. MINIX 3 possui processos especiais do sistema, como Clock e System. Tais processos são apenas visualizados pelo Kernel, e não possuem PID, nem pertencem a alguma árvore de processos. O gerente de processos é o primeiro processo executado no espaço usuário, recebendo PID 0, e não possui pai nem filhos. O processo raiz da árvore de processos é o reincarnation server que possui como filho os processos do sistema, e acompanha o funcionamento destes. Um deles é o processo Init, que recebe PID 1, assim como nos sistemas UNIX, ele é o antecessor de qualquer processo usuário. Para trabalhar com processos, o MINIX 3 oferece duas chamadas de sistemas principais, o

3 fork e o exec. O fork é o único modo de se criar um novo processo, e o exec permite carregar um programa num processo já criado. O tamanho de espaço a ser alocado para o processo é especificado no cabeçalho do programa. As informações dos processos são armazenados numa tabela de processos, dividida entre os processos, Kernel, Gerente de Processos e Sistema de Arquivos. A comunicação entre processos é realizada pro três primitivas, send, receive e sendrec. Cada um recebe dois parâmetros. O primeiro sendo o processo destino/origem, e o segundo o local de memória que contém a informação da mensagem. A transferência de mensagens, geralmente, ocorre de cima para baixo, nas camadas de processos. Processos usuários não podem enviar mensagens entre si diretamente, apenas tendo o sistema como intermediário. O sistema de troca de mensagens do MINIX 3 utiliza a técnica rendezvous. Deste modo, quando um processo A envia uma mensagem para outro processo B, A ficará bloqueado até que o processo B receba a mensagem. Assim, não é preciso buffers de caixa postal para controle de mensagens, e visto que todas as mensagens possuem tamanho fixo, erros de estouro de buffers são prevenidos. Uma outra primitiva oferecia pelo sistema é o notify. Esta chamada é utilizada para avisar outro processo de algo importante sem ser bloqueado. Deste modo, notify é assíncrono. Entretanto, um simples mapa de bits é suficiente para controlar os notify's dos processos. Em alguns casos, o notify já é uma mensagem suficiente para a comunicação, quando não há ambiguidade na mensagem. Para se criar um sistema operacional multiprogramável, é necessário um controle de interrupções. A camada mais inferior do MINIX 3 é a responsável em aumentar o nível de abstração das interrupções para mensagens. Por exemplo, as chamadas send e receive, acima mencionadas são traps, ou seja, interrupções geradas pro software. O escalonador do MINIX 3 trabalha com sistema de filas em multi-nível. Dezesseis filas com prioridades são definidas pelo sistema. A camada de mais baixa prioridade é utilizada para processos de segundo plano, apenas executados quando não há nada a fazer. Processos usuários possuem uma prioridade intermediária. Os processos de camadas mais inferiores possuem maiores prioridades. Os processos Servers possuem prioridade acima do permitido para processos usuários. Processos Drivers possuem prioridade acima dos Servers e os processos do Kernel ocupam a fila de maior prioridade. As filas não são estáticas, os processos podem se mover entre as filas utilizando, por exemplo, o comando nice, igual ao sistema UNIX. Além de filas multi-nível, também é atribuído diferentes quantum para cada processos. Processos usuários possuem um valor de quantum baixo. Processos Drivers e Servers deveriam executar até serem bloqueados, ou seja, processos de tempo real. Mas, por segurança, são processos preemptiveis, entretanto possuem um alto valor de quantum. O processo Clock é o responsável pelo controle do tempo de execução dos processos. Para garantir que processos de mais baixa prioridade também possam ser executados, o MINIX 3 utiliza uma técnica semelhante ao de envelhecimento. Se um processo A que utilizou todo o seu quantum for reescalonado para a CPU, e isto estiver impedindo outros processos de executar, então A terá sua prioridade reduzida. Em algum momento, todos os processos terão sua chance de utilizar a CPU. Caso A utilize todo o seu quantum sem impedir outros processos de executar, então A terá sua prioridade promovida para o seu máximo permitido para o processo A. Dentro das filas o algoritmo de alternância obrigatória é utilizado, com uma pequena alteração. Se um processo, durante sua execução for bloqueado, quando este se tornar pronto novamente, será colocado no início da fila e irá utilizar o restante de seu quantum. Agora, se um processo utiliza todo o seu quantum, então será colocado no final da fila. O escalonador escolhe um processo da fila de mais alta prioridade para executar, se não tiver nenhum processo pronto na fila, então a fila de prioridade subsequente será analisada. Pela dependência dos processos Drivers com os Servers e deste último com os processos usuários, os processos Drivers e Servers, normalmente, ficam em estado bloqueado, permitindo a execução dos processos usuários. Gerenciamento de memória O gerenciamento de memória no MINIX 3 é extremamente simples. Diferente de outros SO's, não são utilizados paginação nem swapping, sendo que o gerenciador de memória mantém uma lista de espaços que são classificados por ordem de endereçamento de memória. Esse tipo de gerenciamento foi implementado por três motivos principais: 1º) Manter o MINIX como ferramenta de estudo, de fácil compreensão; 2º) MINIX funcionando em todos os IBM PC: alguns sistemas simples dessa família(8088) na arquitetura de gerenciamento de memória não suportam memória virtual nem detecta estouro de pilha. Usando isso ele consegue ampliar a área de atuação do sistema operacional cobrindo essa categoria primitiva que ainda são aproveitadas e estão em uso.

4 3º) Portabilidade: implementação simples e direta em computadores pequenos, ou seja, quanto menor for a gama de suposições de hardware maior será o numero de maquinas para poder portá-lo. Além desses motivos há outros, por exemplo o fato do MINIX ser destinado a computadores pessoais, que implica que a média de processos em execução será pequena, havendo assim memória disponível para armazenar todos os processos correntes. A implementação do gerenciamento de memória é diferente, pois separa a política(quais processos e onde irão ser alocados) do mecanismo(mapa de memoria para os processos), esse gerenciamento não faz parte do kernel, ele é manipulado pelo processo gerenciador de memória executado no espaço do usuário e faz comunicação com kernel pelo mecanismo padrão de mensagens. O layout de memória utiliza dois modelos, espaços de instruções e dados (I&D) combinados, onde todas as partes do processo compartilham o mesmo espaço de memória, ou seja, todas as partes do processo(texto, dados e pilha) são alocados e liberado como um bloco unico, ou separados, mantém separados os dados das instruções, pode ser mais eficiente mas requer um melhor gerenciamento. A alocação de memória é feita em duas ocasiões, executando um FORK (processo cria um filho) ou EXEC(processo altera sua imagem, ficando livre e alocando a nova imagem). O sistema abaixo utiliza para I&D combinado: Figura 2 Alocação de memória. (a)original com processos A e B (b) Após A ter executado FORK() (c) Após o filho de A ter executado um EXEC Agora quando o MINIX é implementado em um computador com gerenciamento melhor de memória é mais conveniente utilizar o I&D separado onde há o aproveitamento do modo expandido de gerenciamento chamado texto compartilhado, um exemplo seria se um processo executando um fork( ), somente a quantidade de memória necessária para a copiar dos dados e da pilha é alocado e codigo executável, já em uso pelo pai, é compartilhado pelo filho, ou quando executado um exec( ) onde é feita uma pesquisa na tabela de processos para verificar se outro processo já esta utilizando o código executável necessário, se caso encontre ele aloca na memória somente os dados e a pilha compartilhando a área de texto. A desvantagem desse modo é que após terminar o processo ele desaloca os dados e a pilha da memória mas antes de desalocar o segmento de texto ele percorre uma tabela de processos verificando se não há nenhum processo utilizando o segmento de texto. Figura 3 (a)programa armazenado em disco (b) Programa alocado na memória para um único processo No segmento cabeçalho tem-se informações sobre o tamanho que cada segmento ira ocupar na memória e o tamanho total que o processo ocupara no disco, esse espaço total pode ser alterado pelo comando chmem, exemplo se um processo tem 4K de texto, 2K de dados, 1K de pilha e o cabeçalho indica q o espaço total é 40K então a lacuna terá 33K. Essa lacuna fica disponível para que o segmento de dados e pilha consumam durante a execução, esse limite pode ser movido com a chamada de sistema BRK que apenas verifica se o novo segmento de dados entra em colisão com o ponteiro atual da pilha, e se não ele altera alguns dados nas tabelas internas, caso colidam gera uma falha, mas em hipótese alguma há alocação de novo espaço de memória. Conclusões Ao término do projeto, após analisar o MINIX e do estudo teórico de Sistemas Operacionais, foi possível encontrar diversas semelhanças entre outros SO s modernos e o MINIX. Os SO s, contudo, não são idênticos. Primando pela modularização e simplicidade de código, verificamos que o MINIX, apesar de simples, cumpre seu propósito de ser um SO didático, leve e portável. Seu modelo para memória, que não usa paginação, apesar de poder ser visto como muito simplificado, ajuda a entender o código, e não impede que o MINIX seja usado nas circunstâncias apropriadas.

5 As semelhanças são muitas também com o UNIX, apesar de seu código ter sido desenvolvido de forma independente. O modelo de criação e gerência de processos segue basicamente o mesmo, com a criação de um processo init, e os demais processos de usuário sendo criados como filhos deste. Dada sua simplicidade, o MINIX pode ser visto como a base de um SO. Ele possui módulos bem construídos, e um usuário de MINIX poderia criar suas próprias funcionalidades para suas necessidades (como foi o caso de Linus Torvalds, ao criar o Linux). Sendo de código totalmente aberto, seus algoritmos de escalonamento, paginação e diversos outros podem ser modificados de acordo com o uso, de modo que um usuário poderia aumentar seu desempenho em tarefas muito específicas. Também foi interessante estudar o papel do MINIX no nascimento dos softwares de código aberto, sendo um SO feito a partir de outro (que não era mais liberado para estudos acadêmicos) e conseguindo se sobrepor às limitações de licença de código e ganhando espaço nas aulas de Sistemas Operacionais. Por fim, concluímos que o MINIX é um sistema operacional que cumpre seu propósito como software desenvolvido para fins acadêmicos, simples, confiável, portável e modular. Para outras aplicações que não o ensino, o usuário talvez prefira algum SO mais robusto, ou ainda decida implementar soluções mais interessantes para problemas que o MINIX, devido ao seu compromisso com o minimalismo, prefere não tratar. Referências [1] - TANENBAUM, Andrew S; WOODHULL, Albert S. Operating systems: design and implementation. 3 ed. Upper Saddle River, N.J: Pearson/Prentice Hall, c2006. xvii