atividades práticas no ensino introdutório de sistemas...

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.


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


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.


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

} }


•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;}


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.

atividades práticas no ensino introdutório de sistemas...

Documents