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

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.

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 20.000 linhas de código, é simples e bem documentado.

•Disponível no site:

•http://minix1.woodhull.com/faq/minixcd08.html

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:

http://www.inf.ufrgs.br/~asc/sisop/nachos/

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.

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:

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

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:

http://fabrice.bellard.free.fr/qemu

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.

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.

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.

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, observa-se 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.

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.

while (true) {fork();}

Exemplo de Fork Bomb

•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.

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.

Problemas de concorrência

•Variáveis de Bloqueio (lock)

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.

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();

} }

Problemas de concorrência

•Solução de Peterson

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.

Exemplo de Solução de Peterson

#define FALSE 0#define TRUE 1#define N 2int 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;}

Problemas de concorrência

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.

Exemplos de memory bomb

while (1)

{malloc(1024);

}

Char * buf;

Buf = (char*) malloc(5*sizeof(char));

…

free(buf);

strcmp(buf, “memory bomb”);

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.

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.

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.

FIM