Jantar dos filsofos

O problema do jantar dos filsofos, figurativamente falando: temos um

nmero x pessoas em uma mesa, cada uma com um prato de espaguete e
um garfo (um recurso compartilhado), mas para comer seu prprio
espaguete ele precisa do seu prprio garfo mais o garfo do vizinho. Eles
podem ficar em 3 estados, pensando, famintos e comendo, e pelo fato de
todos poderem ficar famintos ao mesmo tempo, gera-se conflito, ou do
ponto de vista computacional um deadlock.
A soluo deve se a implementao de 2 tipos de semforos de controle,
um para avisar que determinado processo est com inteno de entrar na
regio crtica, e outro que ser individual para cada processo que impedir
ou no que determinado processo acesse a regio crtica, sendo assim
funcionando da seguinte maneira (em uma situao hipottica) : 5
processos, no caso lidos de 0 a 4, o processo 0 inicia, o primeiro semforo
apagado(indicando que ele tem inteno de entrar na regio critica), aps
fazer isso ele checa se o anterior dele (no caso o 4) e o posterior (no caso o
1) esto comendo (pois se estiverem os recursos esto ocupados), se no
estiverem seu semforo acende e ele muda seu estado para comendo
aps isso apaga (agora fazendo uso de seu recurso mais o do vizinho
nmero 1). Mas temos que lembrar do clock, temos os outros processos,
digamos que o tempo do processo 0 tenha acabado, o do 1 inicia, seu
semforo passa a indicar que ele tem a inteno de utilizar a regio crtica,
mas quando ele vai ser testado, visto que o processo 0 est a utilizar seu
recurso, seu semforo individual nem chega a acender e ele fica em loop
at que seu tempo acabe. Sendo assim apenas o processo 0 e o processo 2
teriam passado para o estado comendo pois o processo0 est utilizando o
recurso do processo1, e o processo 2 est utilizando o do 3, restando o 4
que no pode pegar de mais ningum. Quando voltar a vez do processo 0 e
ele terminar de comer seu semforo volta a indicar interesse em mexer
na regio crtica, aps isso ele devolve o recurso dos vizinhos, e os coloca
em teste para checar se seus determinados anteriores e posteriores
estariam comendo, se no, como eles j teriam os recursos disponveis,
poderiam comear a comer e assim sucessivamente, at que os
processos se encerrem.
Escritores e Leitores
Basicamente um esquema de competio e ordenao, onde temos
leitores, escritores e um banco de dados, em que podemos ter um escritor
alterando um determinado banco de dados e enquanto isso, no possvel
ter leitores (pois podem ler informaes erradas ) e nem outros escritores
(para evitar conflito de informaes), e quando o escritor termina a edio,
leitores podem ter acesso, inclusive se novos leitores chegarem, podem ser
admitidos, porm, se um escritor quiser ter acesso ao banco de dados, ele
seria suspenso, at que os leitores terminassem, o problema , em alguns
casos os leitores no parariam de chegar, logo o escritor esperaria
infinitamente. Uma soluo para determinada situao foi, tratar a chegada
de um novo escritor como um divisor de aguas, sendo assim quando um
escritor solicitasse acesso ao banco de dados ele ficaria em espera, e os
leitores que fossem chegando aps o escritor, esperariam a vez do mesmo e

somente aps o termino da edio eles poderiam ter acesso ao banco de

dados.
Barbeiro sonolento
Podemos levar o problema do barbeiro sonolento de forma parecida com o
exemplo dado em sala, sobre um gerador e um leitor de informao porm,
no caso atual temos o Cliente, que pode acrescentar a fila de Clientes em
espera e o Barbeiro, que pode diminui-la. Neste problema temos a presena
do mutex para controlar se algum processo est ou no em sua rea crtica,
ou seja, se algum processo est alterando a fila de clientes em espera. Caso
estejam, nenhum outro cliente ou o barbeiro podero alterar a fila, afim de
evistar conflito ou perda de clientes desnecessria. Dentro das reas crticas
tambm temos comandos para que cada processo se ponha para dormir em
caso de inexistencia ou ocupao do outro, alm da presena de comandos
para acordar o outro processo em caso de alterao da condio que os
colocou para dormir.