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

[Francisco Reverbel <reverbel@xxxxxxxxxx>]

(Reenviando esta mensagem, agora na codificação ISO-8859-1, pois a
anterior foi armazenada de modo ilegível pelo mhonarc...)

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