Corrigir e reimplementar o PIS para o multicore e singlecore com PCP e PIP

[ErFer7]

Contexto

O Priority Inheritance Solver (PIS) deve ser implementado para todos os algoritmos até agora e deve considerar mutexes e semáforos.

Atenção

Essa issue deve ser feita com base na #39.

Critérios

• Implementar o PIS para mutexes
• Implementar o PIS para semáforos
• Garantir que os PIS funcione em cenários diversos, incluindo a destruição da thread ou dos sincronizadores

[sammycosta]

Atualmente (análise código do Guto):

• Thread possui uma Task, e a Task possui uma lista de recursos; As funções enroll e dismiss inserem e removem elementos nessa lista;

  • Entender se existe uma Task por thread, porque na criação da Thread é passado a current com Task::self() ? Onde ela é criada? No comentário diz // This constructor is only used by Thread::init() TASK POR SISTEMA? TASK POR CORE (atualmente não, mas como é no epos original??)?
  • Alarm faz enroll e dismiss da lista de recursos. Condition, Mutex, Segment, Semaphore também.
  • Threads também entram na lista de recursos da Task no constructor_epilogue!
  • Deleção dos recursos na deleção da Task, i guess

• Algumas coisas são tratadas com eventos no scheduler, pode ser importante entender os eventos ou utilizar sua lógica em outros momentos, o Criterion teria uma handle de eventos; handle no scheduler.cc: majoritariamente atualiza estatísticas, mas também é utilizado pra atualizar a priority em algoritmos dinâmicos -> LLF

• O synchronizer common possui as estruturas:

  • Fila _granted e fila _waiting
  • lock e unlock específico (substituindo os antigos begin_atomic e end_atomic), que chamam thread prioritize e deprioritize, e inserem a Thread na fila _granted somente quando ela está utilizando de fato o recurso;

• Thread.cc:

  • Prioritize: Não parece fazer sentido. A running tem maior prioridade que a que está na lista de granted, então eu deveria atualizar a prioridade do elemento i que está na _granted (lista de quem está em uso do recurso???) para a prioridade da running/ceiling. Parece aqui que ele atualiza a prioridade dela com ela mesma
  • Deprioritize (que roda pra fila _granted e pra _waiting no release da thread): restauraria a prioridade dos elementos da lista, mas tá restaurando o da r toda vez também? Confuso

Estado de run atual:

• Sem priority ligado, travado;
• Priority ligado, diversas exceções

[sammycosta]

erro esquisitinho no make veryclean

meus debugs nem nenhum kout tá dando certo, não consegui seguir as trilhas da exceções por conta disso (nem utilizando gdb)
minha suspeita é o prioritize e deprioritize, mas não consegui mapear. acho que com o clean bugado minhas alterações não tão indo pra mexer direito também, pq dps que eu APAGUEI os prints eles tão aparecendo????????????? e parece que dá exceção em outro ponto que não o prioritize/deprioritize.

Mas o alg dele parece todo esquisito mesmo, nada pronto. A thread não tem os recursos que ela tá usando, o ideal seria restaurar toda essa lógica nossa (talvez usar esse Queue dele ao invés da lista se isso não for o motivo de bug, parece não precisar dos elementos _link) e colocar toda nossa lógica antiga no prioritize e deprioritize, tratando caso específico de semáforo (nos métodos dele ou vendo pelo tipo do recurso)