Aula 29102020 - AULA 08 Parte 1

Prévia do material em texto

Sistemas Operacionais
Sistemas de Informação
Estácio Cabo Frio
Prof. Me. Victor Barreto
victornqs@gmail.com
Tópicos
Comunicação Entre Processos e Threads
Comunicação Entre Processos e Threads
Nos dias atuais temos acesso a computadores com multiprocessadores, os quais, a maioria dos programas levam em
consideração em seu desenvolvimento, para obter melhor desempenho.
Muitos problemas solucionados por um programa não são executados sequencialmente, são divididos em várias tarefas
interdependentes que relacionam entre si a fim de atingir um objetivo comum.
Os códigos dos programas são estruturados de tal forma que permitem serem executados concorrentemente através de
múltiplos processos ou threads. Programas com estas características são chamados de aplicações concorrentes.
Comunicação Entre Processos e Threads
Aplicações concorrentes proporcionam um melhor desempenho mesmo não havendo um paralelismo real na execução
dos processos ou threads. Onde há o paralelismo real, em casos de sistemas com múltiplos processadores, as aplicações
concorrentes melhora ainda mais estas vantagens.
Programas desenvolvidos para serem executados de modo sequencial, que executam apenas um único fluxo por vez, não
se beneficiam das vantagens oferecidas por um sistema com múltiplos processadores.
Programas como editores de texto, navegadores web e jogos, caso fossem um programa sequencial, não teríamos a alta
interatividade que temos nestas aplicações. Os editores de texto, por exemplo, permitem a digitação enquanto efetuam
a revisão ortográfica.
Comunicação Entre Processos e Threads
Os bancos de dados, essencial nas aplicações atuais, principalmente aplicações empresariais como Sistema integrado de
gestão empresarial (SIGE ou ERP – Enterprise Resource Planning) são outro exemplo de aplicações concorrentes.
Um sistema ERP integra todos os dados e processo de uma organização em um único sistema e estes dados são
armazenados em um banco de dados. Caso o banco de dados utilizado por um ERP fosse sequencial, atenderia um único
usuário por vez. Logo se um usuário estivesse dando entrada de mercadoria no estoque, todo o restante da empresa
estaria parado, aguardando o término desta tarefa, tornando este tipo de sistema inviável para uma empresa.
Comunicação Entre Processos e Threads
Para que os processos concorrentes possam cooperar entre si, é necessário que haja uma comunicação entre eles para
troca e compartilhamento de informações, além de um sincronismo, efetuado pelos sistemas operacionais para que as
atividades sejam executadas sem erros.
Diversos mecanismos podem ser utilizados para efetuar a comunicação entre os processos, como variáveis
compartilhadas na memória principal, quanto à memória é compartilhada entre os processos. Quando a memória não é
compartilhada, os processos podem trocar mensagens para compartilhar as informações entre si.
Comunicação Entre Processos e Threads
Acessando arquivo e impressora através de um programa sequencial. Fonte: Oliveira et al. (2010)
As três operações feitas utilizando um programa sequencial. Neste caso é utilizado apenas um processo.
Comunicação Entre Processos e Threads
Acessando arquivo e impressora através de um programa concorrente. Fonte: Oliveira et al. (2010)
Através do gráfico, podemos notar a utilização
simultânea do disco e da impressora. Dessa forma, o
tempo de impressão será bem menor o que torna o
programa concorrente mais eficiente que o programa
sequencial.
Comunicação Entre Processos e Threads
Através do gráfico, podemos notar a utilização
simultânea do disco e da impressora. Dessa forma, o
tempo de impressão será bem menor o que torna o
programa concorrente mais eficiente que o programa
sequencial.
Comunicação Entre Processos e Threads
Processos em execução no sistema operacional podem ser:
• Independentes:
• Quando não podem ser afetados pela execução de outro processo
• Cooperantes
• Quando podem ser afetados pela execução de outro processo
Já sabendo que compartilhamento causa problemas, é mais fácil criar processos independentes!!
Motivação:
Comunicação Entre Processos e Threads
Entretanto, é extremamente desejável criar um ambiente com processos cooperantes!
• Porque?
• Compartilhamento de informações
• Aumento da velocidade de computação
• Modularidade
• Dar suporte a execução de várias tarefas
• Processos cooperantes requerem comunicação entre processos (Interprocess communication – IPC)
Motivação:
Comunicação Entre Processos e Threads
• Mecanismo que permite aos processos trocarem dados ou informações.
• Comunicação entre processos não usa interrupção!
• Frequentemente é feita de duas formas:
• Troca de mensagens
• Compartilhamento de memória
Reforçando:
Comunicação Entre Processos e Threads
• Se pensarmos numa arquitetura centralizada, os processos estão na mesma máquina.
• Diferentes processos têm acesso aos mesmos recursos.
• O que acontece se a arquitetura do sistema for distribuída? (um chat, por exemplo)
• Como os processos podem se comunicar?
Troca de Mensagens:
Comunicação Entre Processos e Threads
• Processos podem se comunicar por troca de mensagens.
• Frequentemente quando estão em diferentes máquinas e precisam compartilhar dados
• A troca de mensagens é feita baseada em duas primitivas:
• send()
• receive()
• Mensagens podem ter tamanho fixo ou variável
• Se dois processos precisam se comunicar, deve haver um link entre eles.
Troca de Mensagens:
Comunicação Entre Processos e Threads
Troca de Mensagens:
• Troca de mensagens por sincronização:
• Blocking send: processo que envia a mensagem fica bloqueado até a confirmação do recebimento
• Nonblocking send: processo envia a mensagem e vai executar a próxima instrução
• Blocking receive: receptor fica bloqueado até que a mensagem esteja disponível
• Nonbloking receive: o receptor devolve uma mensagem válida ou nula.
Comunicação Entre Processos e Threads
Troca de Mensagens:
• Troca de mensagens por bufferização:
• Zero capacity
• Bouded-capacity
• Unbouded-capacity
Comunicação Entre Processos e Threads
Compartilhamento deMemória:
• Processos devem definir uma área de memória que será compartilhada;
• Por padrão o sistema operacional não permite que um processo acesse outro processo!
• Como resolver???
Comunicação Entre Processos e Threads
Compartilhamento deMemória:
• Caso dois processos desejem compartilhar memória, ambos precisam assumir as consequências de não considerar as
restrições do sistema operacional;
• Processos trocam informações através de leituras e escritas numa área compartilhada;
• O sistema operacional não controla esta operação!
• O que os processos precisam garantir??
Comunicação Entre Processos e Threads
Compartilhamento deMemória:
O que acontece quando dois processos querem escrever na mesma área de memória no
mesmo instante?
Comunicação Entre Processos e Threads
Race condition:
Em alguns sistemas operacionais, processos cooperantes frequentemente compartilham algum dispositivo de
armazenamento.
• Arquivos
• Memória
• Disco
Comunicação Entre Processos e Threads
Race condition:
Dois processos podem tentar ler ou escrever dados num espaço compartilhado, e o resultado final depende de quem
está executando naquele momento.
Comunicação Entre Processos e Threads
Race condition Exemplo:
PRODUTOR vs. CONSUMIDOR: Dois processos compartilham um buffer de tamanho fixo. Um deles (processo produtor)
coloca dados no buffer. O outro ( processo consumidor), remove estes dados.
Você consegue ver o problema?
Comunicação Entre Processos e Threads
Race condition:
Como evitar condições de corrida? Sincronizando os processos.
Ou seja, proibindo que mais de um processo possa ler ou escrever numa área compartilhada ao mesmo tempo.
Comunicação Entre Processos e Threads
Exclusão Mútua:
Mecanismo que garante que cada processo que usa uma área compartilhada terá acesso exclusivo a mesma.
Qual é o problema da exclusãomútua??
Comunicação Entre Processos e Threads
Exclusão Mútua:
Pense no problema do PRODUTOR vs. CONSUMIDOR.
O que acontece se quando o produtor estiver armazenando um item, o consumidor não puder consumir nada?
Comunicação Entre Processos e Threads
Exclusão Mútua:
• Dois processos não podem estar simultaneamente em suas regiões críticas. Região crítica (ou Sessão crítica) é uma
parte do código (programa) que contém as operações sobre dados compartilhados, a serem executadas em exclusão
mútua.
• Nada pode ser assumido com relação a velocidade dos processos ou quantidade de processadores disponível
• Nenhum processo fora de sua região crítica pode bloquear um processo que esteja na região crítica
• Nenhum processo deve esperar indefinidamente para entrar na região crítica.
Comunicação Entre Processos e Threads
Exclusão Mútua Como Implementar:
• Espera ocupada
• Sleep and wakeup
• Semáforos
• Mutex
• Monitores
Comunicação Entre Processos e Threads
Exclusão Mútua – Espera Ocupada:
• Premissa da espera ocupada:
• Enquanto um processo executa na região crítica, o outro apenas espera.
• Formas de implementar:
• Interrupção:
• Problema: não é ideal que processos tenham controle sobre as interrupções
Comunicação Entre Processos e Threads
Exclusão Mútua – Espera Ocupada:
• Formas de implementar:
• Alternância Obrigatória
Comunicação Entre Processos e Threads
Exclusão Mútua – Sleep e Wakeup:
• Primitivas (chamadas de sistemas)
• sleep()
• Bloqueia um processo enquanto aguarda um recurso
• wakeup()
• Ativa o processo quando o recurso foi liberado
Starvation
Starvation (inaniação): quando um processo não consegue ser executado, de forma alguma, pois sempre existem
processos de prioridade maior para serem executados, de forma que o processo "faminto" nunca consiga tempo de
processamento.
Em um ambiente computacional multitarefa, a execução de diversos processos simultâneos deve seguir uma regra de
escalonamento destes para uso do processador. Isso se deve ao fato de que, durante a mudança de contexto pelo
processador, é feita a escolha do próximo processo a ser executado a partir da prioridade deste. Quando o
escalonamento não é feito adequadamente, pode ocorrer o problema. Uma solução para esta situação é a delegação de
um tempo máximo de espera.
Deadlock
Deadlock:, quando ocorre um impasse, e dois ou mais processos ficam impedidos de continuar suas execuções - ou seja,
ficam bloqueados, esperando uns pelos outros.
• O deadlock pode ocorrer mesmo que haja somente um processo no SO, considerando que este processo utilize
múltiplos threads e que tais threads requisitem os recursos alocados a outros threads no mesmo processo;
• O deadlock independe da quantidade de recursos disponíveis no sistema;
• Normalmente o deadlock ocorre com recursos, tais como dispositivos, arquivos, memória etc.
Deadlock
Deadlock
Assim, nenhum processo consegue executar recurso que precisa, ou liberar recurso que está de posse, ou ser acordado,
pois o recurso que precisa está ocupado.
Vale detalhar que recurso é uma sequência de eventos necessários ao uso de um processo, assim pode ser dispositivos
ou qualquer item compartilhado.
Deadlock
Uma situação de deadlock pode surgir se as quatro condições a seguir ocorrerem simultaneamente em
um sistema:
Exclusão mútua: Pelo menos um recurso deve ser mantido em modalidade não compartilhável; isto é, apenas um
processo de cada vez pode usar o recurso. Se outro processo solicitar esse recurso, o processo solicitante deve ser
atrasado até que o recurso tenha sido liberado.
Retenção e espera: Um processo deve estar de posse de pelo menos um recurso e esperando para adquirir recursos
adicionais que estejam no momento sendo retidos por outros processos.
Inexistência de preempção: Os recursos não podem ser interceptados; isto é, um recurso pode ser liberado apenas
voluntariamente pelo processo que o estiver retendo, após esse processo ter completado sua tarefa.
Espera circular: Deve haver um conjunto {P0,P1, ...,Pn} de processos em espera tal que P0esteja esperando por um
recurso retido por P1, P1 esteja esperando por um recurso retido por P2, ...,Pn-1 esteja esperando por um recurso retido
por Pn, e Pn esteja esperando por um recurso retido porP0.
Deadlock
Considere cinco filósofos que passam suas vidas pensando e comendo. Os filósofos compartilham uma mesa circular
rodeada por cinco cadeiras, cada uma pertencendo a um deles. No centro da mesa está uma tigela de arroz, e a mesa
está posta com cinco hashis individuais.
Quando um filósofo pensa, ele não interage com seus colegas. Periodicamente, um filósofo fica com fome e tenta pegar
os dois hashis que estão mais próximos dele (os hashis que estão entre ele e seus vizinhos da esquerda e da direita). Um
filósofo pode pegar somente um hashi de cada vez. É claro que ele não pode pegar um hashi que já esteja na mão de um
vizinho. Quando um filósofo faminto está com seus dois hashis ao mesmo tempo, ele come sem largá-los.
Deadlock
Quando termina de comer, larga seus dois hashis e começa a pensar novamente. O problema dos filósofos comensais é
considerado um problema clássico de sincronização, não por causa de sua importância prática ou porque os cientistas da
computação não gostem de filósofos, mas porque é um exemplo de uma classe ampla de problemas de controle de
concorrência. É uma representação simples da necessidade de alocar vários recursos entre diversos processos de uma
forma livre de deadlocks e de inaniação. Uma solução simples é representar cada hashi com um semáforo. Um
filósofo tenta pegar um hashi executando uma operação wait() nesse semáforo. Ele libera seus hashis executando a
operação signal () nos semáforos apropriados.
Deadlock
Portanto, os dados compartilhados são:
semaphore hashis[5];
Em que todos os elementos de hashi são inicializados com 1. A estrutura do filósofo i é mostrada na próxima Figura a
seguir. Embora essa solução garanta que dois vizinhos não comam simultaneamente, ela deve ser rejeitada porque
poderia criar um deadlock. Suponha que todos os cinco filósofos fiquem com fome ao mesmo tempo e que cada um
pegue seu hashi esquerdo. Agora todos os elementos de hashis serão iguais a 0. Quando cada filósofo tentar pegar seu
hashi direito, ficará em estado de suspensão indefinidamente. Várias soluções possíveis para o problema do deadlock
podem ser substituídas por:
Deadlock
Permitir no máximo quatro filósofos sentados à mesa simultaneamente. Permitir que um filósofo pegue seus hashis
apenas se os dois hashis estiverem disponíveis (para fazer isso, ele deve pegá-los em uma seção crítica). Usar uma
solução assimétrica — isto é, um filósofo de número ímpar pega primeiro seu hashi esquerdo e, então, seu hashi direito,
enquanto um filósofo de número par pega seu hashi direito e, então, seu hashi esquerdo.
Observe, no entanto, que qualquer solução satisfatória para o problema dos filósofos comensais deve garantira
impossibilidade de que um dos filósofos morra de fome. Uma solução livre de deadlocks não elimina necessariamente a
possibilidade de inanição.
Deadlock
Estrutura do Filósofo!
Deadlock
Para assegurar que os deadlocks jamais ocorram, o sistema pode usar um esquema para prevenir ou para evitar a
ocorrência de deadlocks. A prevenção de deadlocks fornece um conjunto de métodos para assegurar que pelo menos
uma das condições necessárias não possa ocorrer. Esses métodos previnem a ocorrência de deadlocks restringindo
como as solicitações de recursos podem ser feitas.
Para evitar deadlocks, o sistema operacional deve receber antecipadamente informações adicionais relacionadas com os
recursos que um processo solicitará e usará durante seu tempo de vida. Com esse conhecimento adicional, o sistema
operacional pode decidir, para cada solicitação, se o processo deve ou não esperar. Para decidir se a solicitação corrente
pode ser atendida ou se ela deve ser adiada, o sistema deve consideraros recursos correntemente disponíveis, os
recursos correntemente alocados a cada processo e as futuras solicitações e liberações de cada processo.
Deadlock
Na ausência de algoritmos para a detecção e recuperação de deadlocks, podemos chegar a uma situação em que o
sistema está em estado de deadlock sem ter maneira de reconhecer o que ocorreu. Nesse caso, o deadlock não
detectado resultará na deterioração do desempenho do sistema porque os recursos estão sendo mantidos por
processos que não podem ser executados e porque mais e mais processos, ao fazerem solicitações de recursos,
entrarão em estado de deadlock. Eventualmente, o sistema parará de funcionar e terá que ser reiniciado manualmente.
Embora esse método possa não parecer uma abordagem viável para o problema do deadlock, ele é usado na maioria dos
sistemas operacionais, como mencionado anteriormente. O custo é uma consideração importante. Ignorar a
possibilidade de ocorrência de deadlocks é mais barato do que as outras abordagens. Já que em muitos sistemas os
deadlocks ocorrem com pouca frequência (digamos, uma vez por ano), o custo adicional dos outros métodos pode não
valer a pena.
Recuperação de Deadlock
Quando um algoritmo de detecção determina que existe um deadlock, várias alternativas estão disponíveis. Uma
possibilidade é informar ao operador que ocorreu um deadlock e deixa-lo lidar com o problema manualmente. Outra
possibilidade é permitir que o sistema se recupere do deadlock automaticamente. Há duas opções para a interrupção
deum deadlock. Uma é simplesmente abortar um ou mais processos para romper a espera circular. A outra é provocar a
preempção de alguns recursos de um ou mais dos processos em deadlock.
Recuperação de Deadlock
Abortar todos os processos em deadlock; ou Abortar um processo de cada vez até que o ciclo do deadlock seja
eliminado
Pode não ser fácil abortar um processo. Se o processo estava no meio da atualização de um arquivo, seu encerramento
deixará esse arquivo em um estado incorreto. Da mesma forma, se o processo estava no meio da impressão de dados em
uma impressora, o sistema deve reposicionar a impressora para um estado correto antes de imprimir o próximo job. Se o
método de encerramento parcial for usado, então devemos determinar que processo (ou processos) do deadlock deve
ser encerrado. Essa determinação é uma decisão política, semelhante às decisões de scheduling da CPU. A questão é
basicamente econômica; devemos abortar os processos cujo encerramento incorrerá no custo mínimo. Infelizmente, o
termo custo mínimo não é preciso.
Sincronização Entre Processos e Threads
A eficiência decorre do trabalho cooperativo entre os processos e do acesso compartilhado de recursos, como memória,
dispositivos de entrada/saída e arquivos. Em muitos casos o acesso a compartilhado pode gerar situações de
inconsistência de informações ou problemas intermitentes de difícil reprodução e solução do mesmo. Estes problemas
impulsionaram a criação de mecanismos nos sistemas operacionais a fim de ordenar a execução dos processos,
chamados de sincronização.
Com relação a gerenciamento de processos: o SOLARIS trata os threads em nível de usuário e de Kernel da mesma forma
e ainda possui processamento simétrico. Com relação a política de escalonamento de processos, ela é preemptiva,
utilizando um misto de múltiplas filas, um contador de programa e troca de contexto. Usando semáforos e monitores
para a primitiva de sincronização. Já para o gerenciamento de memória o Kernel do sistema operacional é o grande
responsável por realizar esse gerenciamento.
Sincronização Entre Processos e Threads
Semáforos
Uso de semáforos:
Alocação de recursos;
Para permitir que mais de um recurso acesse a região crítica ao mesmo tempo (caso de recursos compartilhados);
Semáforos
Variável utilizada para controlar o acesso a recursos compartilhados.
O semáforo é uma variável inteira que pode ser mudada por apenas duas operações primitivas: P e V.
P = proberen (testar) e V = verhogen (incrementar).
Fundamentalmente a ideia é utilizar o semáforo (S) para permitir a cooperação entre processos por meio de sinais. Dessa
maneira, um processo pode ser forçado a esperar num determinado lugar até que receba um sinal específico.
Semáforos
Para receber um sinal, usa-se P(S)
Para transmitir um sinal, usa-se V(S)
Quando um processo executa uma operação P, o valor do semáforo é decrementado. O processo pode ser
eventualmente bloqueado e inserido na fila de espera do semáforo. Numa operação V, o semáforo é incrementado e,
eventualmente, um processo que aguarda na fila de espera deste semáforo é acordado.
A operação P também é comumente referenciada como DOWN ou WAIT, e a operação V como UP ou SIGNAL.
Semáforos que assumem somente valores 0 e 1 são denominados semáforos binpários ou mutex. Neste caso, P e V são
também chamadas de LOCK e UNLOCK.
Monitores
A comunicação interprocessos utilizando semáforos e contadores de eventos parece ser a solução definitiva. Entretanto,
se analisarmos mais diretamente estas técnicas, veremos que elas possuem alguns problemas: São tão primitivos que é
difícil expressar soluções para problemas de concorrência mais complexos.
Para tornar mais fácil a escrita de programas corretos, Hoare (1974) e Brinch Hansen (1975) propuseram uma primitiva
de sincronização de alto nível chamada de monitor. Um monitor é uma coleção de procedimentos, variáveis, e estruturas
de dados que são todos agrupados em um tipo especial de módulo ou pacote. Processos podem chamar os
procedimentos em um monitor sempre que o desejarem, mas eles não podem diretamente acessar as estruturas de
dados internas do monitor através de procedimentos declarados fora do monitor.
Monitores
Monitores possuem uma importante propriedade que os torna uteis para atingir exclusão mútua: somente um processo
pode estar ativo em um monitor em qualquer momento.
Monitores são uma construção da própria linguagem de programação utilizada, de forma que o compilador sabe que
eles são especiais, e pode manipular chamadas a procedimentos dos monitores de forma diferente da qual manipula
outras chamadas de procedimentos.
Ao fazer a exclusão mútua de regiões críticas automáticas, monitores fazem com que a programação paralela seja muito
menos sujeita a erros do que com semáforos. Entretanto, monitores possuem suas desvantagens.
Transações Atômicas
Método de abstração de sincronização em sistemas distribuídos de nível mais alto, ocultando semáforos, monitores e
trocas de mensagens.
Vantagens: O programador concentra-se na maneira que os processos trabalham em paralelo, nos algoritimos das
aplicações.
Uma coleção de operações que executa uma função lógica forma uma transação.
Transações Atômicas
Transações são utilizadas para proteger dados compartilhados.
Um processo pode acessar e modificar múltiplos itens de dados como uma operação atômica.
Ex: usuário deseja debitar valor de uma conta e creditar esse valor em outra conta:
Debitar (conta1, valor1)
Creditar (conta2, valor1)
Ocorre de forma indivisível.
Transações Atômicas
O exemplo clássico para a necessidade de uma "transação atômica" é aquele da transferência entre duas contas
bancárias. No momento de uma transferência de valores de uma conta "A" para uma conta "B", que envolve pelo menos
uma operações de ajuste no saldo para cada conta, se o computador responsável pela operação é desligado por falta de
energia, espera-se que o saldo de ambas as contas não tenha se alterado. Neste caso são utilizados sistemas que
suportam transações atômicas.
Comunicação Entre Processos e Threads
Exercícios
Defina:
• Programação concorrente
• Condição de corrida
• Exclusão Mútua
• Região Crítica
• O que é necessário para garantir para que seja possível implementar uma boa solução de exclusão mútua?
• O que são primitivas?
• Como pode ocorrer a comunicação entre processos?
• Em qual situação devemos usar cada um dos mecanismos de IPC?Justifique.
Referências
BALIEIRO, R. Sistemas Operacionais[BV:RE]. 1. Rio de Janeiro: SESES, 2015. Disponível em: http://repositorio.savaestacio.com.br/site/index.html#/objeto/detalhes/80FEA820-1CB5-4982-863F-25F09ADBDD0C
CASTRO, Arleys. Threads. Disponível em https://slideplayer.com.br/slide/10572685/, acessado em 27/08/2020.
Córdova Junior, Ramiro Sebastião. Sistemas Operacionais[BV:MB]. 1ª Edição. Porto Alegre:: SAGAH,, 2018.Disponível em:
https://integrada.minhabiblioteca.com.br/#/books/9788595027336/cfi/1!/4/4@0.00:58.4
Costa, Patrícia Dockhorn. Sincronização de Processos: Semáforos. Disponível em: http://www.inf.ufes.br/~pdcosta/ensino/2008-1-sistemas-operacionais/Slides/Aula12-4slides.pdf
Deitel, Harvey M.; Deitel, Paul J.; Choffnes, David R. Sistemas Operacionais[BV:PE]. 3. São Paulo: Pearson Prentice Hall, 2005. Disponível em: https://plataforma.bvirtual.com.br/Leitor/Publicacao/315/pdf
Francis Berenger Machado, Luiz Paulo Maia. Arquitetura de Sistemas Operacionais[BV:MB]. 5. ed. - [Reimpr.].. Rio de Janeiro: LTC, 2017. Disponível em: https://integrada.minhabiblioteca.com.br/#/books/978-
85-216-2288-8/cfi/5!/4/4@0.00:0.00
Maristela, Flávia. Comunicação entre Processoos. Disponível em: https://ads.ifba.edu.br/dl1024
Oliveira, Romulo Silva de. Sistemas Operacionais[BV:MB]. 4ª. Porto Alegre: Bookman, 2010. Disponível em: https://integrada.minhabiblioteca.com.br/#/books/9788577806874/cfi/0!/4/4@0.00:0.00
Organizador, Paulo Henrique M. Bittencourt. Ambientes Operacionais[BV:PE]. 1. São Paulo: Pearson Education do Brasil, 2013. Disponível em:
https://plataforma.bvirtual.com.br/Acervo/Publicacao/21293#pageContent
Padro, Sergio. Sistemas de Tempo Real – Parte 1. Disponível em https://sergioprado.org/sistemas-de-tempo-real-part-1/, acessado em 11/08/2020..
https://integrada.minhabiblioteca.com.br/#/books/9788595027336/cfi/1!/4/4@0.00:58.4
Referências
PANTUZA, Gustavo. O que são e como funcionam as Threads. Disponível em https://blog.pantuza.com/artigos/o-que-sao-e-como-funcionam-as-threads, acessado em 27/08/2020.
Puhman, Henrique. Sistemas Operacionais de Tempo Real. Disponível em https://www.embarcados.com.br/sistemas-operacionais-de-tempo-real-rtos/, acessado em 11/08/2020
Santos, Ricardo Ribeiro. Sistemas Distribuídos, 2010. Disponível em: http://www.facom.ufms.br/~ricardo/Courses/DisSys/Material/SD-Aula-09.PDF
Silberschatz, Abraham. Fundamentos de sistemas operacionais [BV:MB]. 9. ed. -. Rio de Janeiro: LTC, 2015. Disponível em: https://integrada.minhabiblioteca.com.br/#/books/978-85-216-3001-
2/cfi/6/2!/4/2/2@0:0
Siqueira, Fernando. Sistemas Operacionais. Disponível em https://sites.google.com/site/proffernandosiqueiraso/aulas/5-processo, acessado em 11/08/2020.
Tanenbaum, Andrew S.; Bos, Herbert. Sistemas Operacionais Modernos[BV:PE]. 4. ed. São Paulo: Pearson Education do Brasil, 2016.Disponível em:
https://plataforma.bvirtual.com.br/Leitor/Publicacao/36876/pdf
UFPE. O Escalonamento de Tempo Real. Disponível em https://www.cin.ufpe.br/~if728/sistemas_tempo_real/livro_farines/cap2.pdf, acessado em 11/08/2020.
http://www.facom.ufms.br/~ricardo/Courses/DisSys/Material/SD-Aula-09.PDF