Atividades Práticas no Ensino Introdutório de Sistemas Operacionais

Transcrição

1 Atividades Práticas no Ensino Introdutório de Sistemas Operacionais

2 Introdução Experiência na utilização de aulas práticas em laboratório, para ensino introdutório de Sistemas Operacionais. Livros-texto levantam a necessidade de praticar implementação em disciplinas teóricas. Silberschatz e Deitel Utilizam Java para elaborar exemplos e exercícios.

3 Ambientes Sistemas operacionais: Minix Desenvolvido na linguagem C para ensino de Sistemas Operacionais. Criado por Andrew S. Tanenbaum Possui código aberto e é baseado em Unix. Inspirou a criação do Linux. Com linhas de código, é simples e bem documentado. Disponível no site:

4 Ambientes Sistemas operacionais: NachOS Simulador de Sistema Operacional desenvolvido na linguagem C/C++, roda sobre uma máquina virtual MIPS. Deve ser compilado para a máquina alvo por uma compilador C++. Utiliza compilador cruzado (cross-compiler) Tipo de compilação que roda na máquina hospedeira mas gera o código para outra máquina. Maiores informações:

5 Ambientes MINIX X NachOS O MINIX é mais portável, tem forte relação com Linux e é mais real, não apenas um simulador. O NachOS é melhor em gerenciamento de memória. Mesmo considerando o prejuízo nas atividades com gerenciamento de memória, o MINIX foi escolhido para as aulas práticas.

6 Ambientes Emuladores: Instalação do MINIX de forma nativa requer partição reservada. Riscos de instabilidade e dificuldade em alterar o kernel. Solução é o uso de emuladores:

7 Ambientes Emuladores: BOCHS Possui código aberto e é altamente portável. Emula CPU, dispositivos e BIOS. Emula SO como Linux, Windows, DOS, MINIX. Executa códigos em tempo de execução, como um processador de Scripts. Disponível para Windows e Linux. Maiores informações: bochs.sourceforge.net

8 Ambientes Emuladores: QEMU Genérico e de código aberto. Desempenho por tradução dinâmica do código. Emula SO completo, incluindo processador e periféricos. É mais eficiente que o BOCHS por sua compilação dinâmica (encontrando trecho de código, converte para instruções da máquina hospedeira). Maiores informações:

9 Ambientes Emuladores são ruins para transportar arquivos internos ao emulador e externos ao SO hospedeiro. O transporte de arquivos é necessário, pois: Atividades não terminam no mesmo momento; Uso de trechos de códigos para relatório; Reaproveitamento de códigos antigos; Edição restrita de arquivos no simulador. Alteração do núcleo pode tornar o sistema instável e ocasionar perda de arquivos. Esse problema deve ser resolvido logo no início.

10 Atividades Comentários sobre as práticas de maior sucesso em aprendizado e interesse. É essencial que as aulas teóricas estejam relacionadas com as aulas práticas, com o aluno atento às duas. São feitos relatórios com as explicações. O foco é praticar o aprendido na teoria. Novas idéias e melhorias não são exigidas.

11 Trocas de contexto Alterar núcleo do sistema. Se uma tecla específica for pressionada, aparece uma mensagem. Todos os passos para realização são indicados detalhadamente. Objetivo é conhecer o ambiente. Alteração adicional. Se uma tecla específica for pressionado, imprimir o número de trocas de contexto. Aluno ignora o significado do número calculado. Depois de testes, recebe explicações sobre trocas de contexto.

12 Tabela de Processos e Chamadas ao Sistema Criar um programa que leia um número N e, usando fork, crie N processos filhos. Cada filho exibe a mensagem Processo X criado (X = id process). Espera 2 segundos (usando sleep) e exibe Filho X terminado. Processo pai espera todos os filhos terminarem (usando wait) e depois imprime Pai terminado. Trabalha com processos e chamadas de sistema. Aumentar N até que fork não consiga criar novos filhos. Testa quantos processo podem ser carregados. Usando ps, observase o limite da tabela de processos. Aumentar tamanho da tabela alterando o kernel. Aluno investiga o código-fonte, a tabela de processos e atributos.

13 Tabela de Processos e Chamadas ao Sistema Mostrar uma Fork Bomb, e analisar as conseqüências. Os alunos costumam se interessar em fazer o sistema travar. Alterar o Kernel limitando a quantidade processos que cada usuário pode criar. Aprende-se assim uma possível solução para sobrecarga.

14 Exemplo de Fork Bomb while (true) { fork(); } dispara a função, que chama a função recursivamente com um pipe para ela mesma, em background. Ou seja, vai crescer exponencialmente até estourar o limite de processos ou deixar a máquina inutilizável.

15 Alterações no Escalonador Alterar o kernel para, a desejo do usuário, acrescer ou decrescer o quantum (em milissegundos.). Fazer testes para verificar quais programas se beneficiam com a mudança. Remover o código que retira o processo do início da fila e coloca no final. Efeitos interessantes no sistema. Trocar algoritmo de Round-Robin por algoritmo garantido. Escolhe o processo que recebeu a menor fatia de CPU. Medir a eficiência do sistema. Percebe-se que pequenas alterações mudam muito o desempenho.

16 Variáveis de Bloqueio (lock) Problemas de concorrência Usa código que indica 2 threads entrando ao mesmo tempo em região crítica. É necessário combinar tempo entre as threads. Existe gasto de tempo inútil entre o lock e a atualização. O aluno percebe que o problema não foi resolvido. Alternação estrita Uma thread fora da região crítica pode impedir a entrada de outra. Códigos alternam entre região crítica e não-crítica e inclusão de gasto de tempo inútil na região não crítica de uma das threads. Percebe-se que a thread com região não-crítica mais demorada impede a outra de entrar na região crítica.

17 Problemas de concorrência Exemplo de Alternância Estrita: Uma variável indica de quem é a vez executar a seção crítica while (TRUE) { while (TRUE) { while (turn!= 0) while (turn!= 1) ; ; secao_critica(); secao_critica(); turn = 1; turn = 0; secao_nao_critica(); secao_nao_critica(); } }

18 Solução de Peterson Problemas de concorrência Independência Total do Hardware. Sofre com o Busy Waiting, como as outras. Usa-se o código da troca de contexto para analisar a quantidade ao realizar o experimento. Compara o resultado com a alternância estrita, que resolveu o problema. Semáforos Mostra que as outras idéias são resolvidas com o uso de semáforos. Usa-se algoritmo do produtor-consumidor, e jantar dos filósofos. Verifica-se comportamento dos códigos, usando mais de 2 Threads, o que acaba mostrando mais uma solução dos semáforos. Alunos que nunca usaram concorrência e threads precisam de auxílio. Se o tempo for curto, fornecem-se os códigos-fonte, e o aluno apenas testa e faz pequenas alterações.

19 Problemas de concorrência Exemplo de Solução de Peterson #define FALSE 0 #define TRUE 1 #define N 2 int turn; int interested[n]; void enter_region(int process) { int other; other = 1 process; interested[process] = TRUE; turn = process; while (turn==process && interested[other]==true) ; } void leave_region(int process) { interested[process] = FALSE; }

20 Depurador de alocações de memória Imprimir informações sobre o processo sempre que houver alocação ou liberação de memória. Criação de um Memory Bomb Criar um programa que aloque e libere memória aleatoriamente. Deve-se ser possível chegar a uma situação de falta de memória.

21 Exemplos de memory bomb while (1) { malloc(1024); } Char * buf; Buf = (char*) malloc(5*sizeof(char)); free(buf); strcmp(buf, memory bomb );

22 Inclusão de Lixeira no Sistema de Arquivos Os sistemas de arquivos, como o do Linux, não tem como desistir de uma remoção já executada. Alterar o gerenciador de arquivos, para transportar arquivos deletados para o diretório /undelete. Dificuldades quando se deletam diretórios ou arquivos de mesmo nome. Cópia do arquivo para /undelete pode ser lenta. Solução: remover o arquivo para o /undelete da própria partição onde estava. Se não existir um undelete, remove-o diretamente. Aluno trabalha com sistema de arquivos, com uma alteração prática para o dia-a-dia. Pode-se também, testar se a alteração diminui muito o desempenho do sistema de arquivos.

23 Resultados da experiência Realizadas na Disciplina de SO durante 4 anos. Semestral, com 2 aulas teóricas e 2 práticas por semana. Aumento do interesse e diminuição de reprovações. Projetos curtos, no início, são mais produtivos que projetos extensos e mais bem elaborados. Uma nova prática é realizada a cada 2 semanas, sendo a maior parte realizada em laboratório. Atividades maiores tiveram pouco resultado..com o uso do Moodle (Modular Object-Oriented Dynamic Learning Environment), constatou-se ser desnecessário o acompanhamento presencial. Mas a maneira tradicional ainda obtém os melhores resultados.

24 Conclusão Projeto Futuro: Atividades com o Kernel Linux. Prática em um sistema largamente utilizado, aumentará o interesse e criará sentimento de alteração de um sistema ainda em produção. A prática em ambientes Unix, não desgeneraliza explicações sobre outros SO, e as técnicas estudadas são empregadas em sistemas comerciais/proprietários.

25 FIM