Exercicio 4/5 – Sistemas Operacionais II – INE5424 – UFSC

Trabalho 4/5 – EPOS
Idle Thread
Timing Mechanisms

    Nos exercícios 4 e 5 deveríamos criar uma Idle-Thread, a qual deveria somente ser escalonada quando não existirem mais processos prontos para execução. Também tínhamos que eiminar bugs, como o timer handler acordar indesejadamente as threads, e remover o busy-waiting do método delay.
    A nova Thread é criada no thread_init.cc, o método passado para ela executar inicialmente é o idle, que foi modificado pra ter um loop, e seu status inicial é WAITING. Para garantir que ela não esteja em nenhuma fila, foram realizadas alterações no método body, para que caso o estado inicial seja WAITING, não acontecer nada. Uma nova variável estática para Thread foi criada, que sempre aponta para a Thread _idle, assim permitindo que qualquer Thread passe a execução para a mesma.
    Foi criado um novo método switch_threads(Thread * next), que faz a mudança da thread atual para a thread recebida como parâmetro. Todos os métodos que chamavam a idle() ao perceberem que não possuia ninguém na fila foram alterados para mudar o contexto para a Thread _idle.
    O construtor de Alarm foi alterado para receber uma Thread ao invés de uma referência para um método. O método delay foi alterado para suspender a Thread e criar um novo Alarm com uma referência para ela. Assim ela é acordada apenas no tempo programado, elimindando o busy-waiting. Para garantir que ao resumir uma Thread não haveria perdas de informações importantes os resumes são dados somente no final do método timer_handler, mantendo a consistência da fila de Alarms.
    O tratador master foi mantido como referência para um método, permitindo que outros tipos de escalonamento sejam definidos. Na definição atual, o mesmo chama o método yield do objeto em execução, caso existam outras Threads prontas para execução ele muda o contexto para a próxima thread. Isto nos gerou outro bug, porque quando a Thread IDLE era executada e chamava o método yield, se já existiam pessoas para continuar a execução ela era inserida na fila de READY, passando a ser tratada como um processo normal. Isso foi corrigido verificando se a thread que estava dando YIELD era a thread _idle, caso fosse, não inseria na lista e não mudava o _state.

Arquivos Modificados:
alarm
thread
alarm
thread_init
thread