Re: [reverbel-mac438] Dúvidas no EP1

[Francisco Reverbel <reverbel@xxxxxxxxxx>]

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