O objetivo desse trabalho é que você entenda parcialmente o funcionamento interno do sistema operacional Minix, em especial no que diz respeito ao controle de processos. Para atingir esse objetivo, proponho algumas alterações ao funcionamento do sistema. O trabalho é dividido em duas partes. Na primeira, a alteração em si é bastante simples. A dificuldade na execução dessa parte está em dominar o procedimento de criação de uma nova chamada de sistema e de recompilação do sistema. Sugiro fortemente que a primeira parte seja concluída antes que se inicie a segunda...
Crie uma função readyp() que retorne
o número de processos na fila de prontos.
Essa função deve ser implementada como uma
chamada ao gerenciador de memória (MM),
e o gerenciador de memória deve ser alterado para
tratar essa nova mensagem.
Para enviar uma mensagem para o processo gerenciador
de memória, utilize a função sendrec,
definida em /usr/include/minix/lib.h.
Crie uma chamada vfork() que seja quase igual
a fork, exceto que não duplica a área de dados do processo.
Isso significa que depois da execução de um vfork()
teremos dois processos compartilhando a mesma área de
dados globais.
A nova chamada será testada com um programa teste padrão, feito por mim. Assim, é importante que ela tenha a sintaxe exata
int vfork()retornando 0 para o processo filho e o identificador do novo processo para o processo pai.
Crie chamadas para criação e manipulação de semáforos.
A chamada sem() deve retornar um identificador
de um novo semáforo, inicializado com valor 0.
As chamadas p(int s) e v(int s)
devem ter o funcionamento padrão de operações
sobre semáforos.
A assinatura das chamadas de manipulação de semáforos deve ser:
int sem(void) int p(int s) int v(int s)onde o retorno é 1 se a chamada foi concluída com sucesso e -1 caso contrário.
As chamadas serão testadas com um programa teste desenvolvido por mim. O programa teste assume que podem ser criados pelo menos 10 semáforos e que cada um pode ter até 10 processos bloqueados a sua espera.
Caso desejem, pode ser desenvolvida uma quarta chamada para liberar um semáforo. Essa chamada não será testada em meu programa teste.
Opcionalmente, cada grupo pode desenvolver duas aplicações exemplo para as primitivas de semáforos criadas. Essas aplicações devem ter caráteristicas bem diferentes uma da outra. Devem poder ser executadas com ou sem o uso dos semáforos, sendo o restante do código bsolutamente idêntico nos dois casos, e a execução sem semáforos deve deixar claro o problema da concorrência.
Essa parte vale 1/2 ponto na média das provas. Serão levados em conta na avaliação dessas aplicações: o grau de interesse do problema retratado, a qualidade da solução com semáforos, a qualidade do código como um todo e a qualidade da documentação.
Na entrega da segunda (agora terceira) parte, não haverá apresentação, apenas a entrega desses disquetes. Por isso, mais uma vez sugiro fortemente que cada grupo teste exaustivamente esta composição de ambiente e os disquetes a serem trazidos. Serão descontados N pontos em trabalhos cujo ambiente de boot e execução não funcionem imediatamente!!!