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.