[Prévia] [Próxima] [Prévia por assunto] [Próxima por assunto]
[Índice cronológico]
[Índice de assunto]
Re: [reverbel-mac438] Dúvidas no EP1
- Subject: Re: [reverbel-mac438] Dúvidas no EP1
- From: Francisco Reverbel <reverbel@xxxxxxxxxx>
- Date: Thu, 13 Apr 2006 17:58:36 -0300
Olà Mariana e Hugo,
On Wed, 2006-04-12 at 12:02 -0300, Mariana Bravo wrote:
> OlÃ.
>
> Temos algumas dÃvidas no ep 1.
>
> Como descobrir o Ãndice i do processo? Por exemplo, como o cÃdigo abaixo
> fica em C:
> process RC [i = 1 to n] {
> print(i);
> }
>
> Isto Ã, como o processo sabe qual o Ãndice dele?
VocÃs podem assumir que hà um limite superior para a quantidade de
operadores (algo como MAX_N_OPS=200, por exemplo), atribuir um nÃmero
fixo a cada operador e fazer com que o programa operador receba o nÃmero
do operador na linha de comando. Nessa soluÃÃo, o nÃmero do operador
seria mais um argumento fornecido pelo usuÃrio do programa operador.
Suponham que os usuÃrios serÃo "bem comportados" e nunca colocarÃo no ar
dois operadores com o mesmo nÃmero.
(Numa aplicaÃÃo real, os operadores provavelmente teriam que fornecer um
username e uma senha para entrar no sistema. O username poderia ser o
prÃprio nÃmero do operador, ou este nÃmero poderia ser obtido a partir
do username... Mas a gente nÃo precisa se preocupar com isso, nosso
objetivo agora à sà brincar com concorrÃncia.)
> Supondo que cada processo sabe seu Ãndice, qual à a regiÃo crÃtica do
> programa?
> Explicando:
> Como temos que manter as informaÃÃes de cada operador na memÃria
> compartilhada para o supervisor gerar o relatÃrio completo dele, faz sentido
> que exista um vetor que guarde essas informaÃÃes.
> No caso, cada operador escreve em sua posiÃÃo do vetor e o supervisor lÃ
> todas as posiÃÃes.
> Isto Ã, um problema de leitor/escritor com apenas 1 escritor por posiÃÃo.
>
> Se for isso, nÃo tem nenhum problema de concorrÃncia a nÃo ser talvez
> impedir o leitor de ler se o escritor estiver escrevendo.
> Mas se for isso nÃo precisa mesmo de um tie breaker ou bakery algorithm para
> resolver.
Esta questÃo à boa!
Reparem que, em geral, um problema de leitor/escritor com 1 leitor e 1
escritor à o mesmo que um problema de regiÃo crÃtica com 2 processos,
pois o leitor e o escritor nÃo devem fazer acesso Ãs variÃveis
compartilhadas simultaneamente. Ou seja: no caso geral hà problema de
concorrÃncia sim.
Mesmo assim, o que vocÃs disseram acima nÃo està fora. Acontece que, no
nosso cenÃrio super simplificado, cada operador precisa apenas atualizar
variÃveis inteiras com o nÃmero de chamadas concluÃdas e o nÃmero de
chamadas em andamento. Como uma das nossas hipÃteses bÃsicas à que o
hardware garante a atomicidade das operaÃÃes de leitura e escrita de
inteiros (para essa hipÃtese ser de fato verdadeira pode ser preciso
impor restriÃÃes de alinhamento, como armazenar inteiros sà em endereÃos
mÃltiplos de 4), vocÃs podem argumentar que a gente nÃo precisa se
preocupar com concorrÃncia neste caso particular. Esse argumento estÃ
correto. Num cenÃrio mais realista, entretanto, os operadores manteriam
mais informaÃÃes para cada chamada (cliente que fez a chamada, assunto
da chamada, etc.) e a concorrÃncia seria um problema (pois o hardware
nÃo garantiria atomicidade dos acessos para leitura ou escrita dessas
informaÃÃes). Ou seja, o software teria que implementar exclusÃo mÃtua!
Neste EP eu quero que vocÃs faÃam de conta que os operadores guardam
mais informaÃÃes (ou seja, que o acesso a essas informaÃÃes nÃo Ã
atÃmico) na memÃria compartilhada e implementem exclusÃo mÃtua no acesso
Ãs informaÃÃes mantidas por cada operador.
Reverbel
>
> Mariana e Hugo