[Pr�via] [Pr�xima] [Pr�via por assunto] [Pr�xima por assunto]
[�ndice cronol�gico] [�ndice de assunto]

Re: Duvida especifica no EP2



Oi Tiago,

Sim, voc� pode fazer a fun��o pr�ximo cliente retornar um ClientePtr ou
receber um BarbeiroPtr, como preferir. Agora que voc� me fez pensar nisso,
me parece que o melhor seria fazer essas duas fun��es receberem um
identificador do barbeiro: 

monitor Barbearia {
     // os campos que voce precisar:
     ...

     // opera��o chamada pelos clientes:

     boolean cortaCabelo() { ... }

     // opera��es chamadas pelos barbeiros:

     void proximoCliente(int iBarbeiro) { ... }
     void corteTerminado(int iBarbeiro) { ... }
}

Vou tentar explicar melhor o que pensei: pode ser bom que o monitor tenha
campos vetoriais, com uma posi��o para cada barbeiro. Algo como

    boolean cadeiraOcupada[N]; // cadeiraOcupada[i] indicaria 
                               // se a cadeira do i-esimo barbeiro 
                               // est� ocupada ou n�o

Se voc� tiver vetores assim, com cada barbeiro s� olhando/mexendo na sua
posi��o do vetor, ent�o � bom passar um n�mero do barbeiro nas chamadas a
proximoCliente() e corteTerminado(). E � bom que esse n�mero seja um
"inteiro pequeno", que sirva como �ndice para acessar a posi��o do 
barbeiro nos vetores que voc� tiver. (Infelizmente os thread ids
retornados por pthread_self() n�o servem, pois n�o s�o "inteiros 
pequenos" alocados a partir de zero.)

� mesmo necess�rio o argumento adicional iBarbeiro? 

Nao. D� para se virar sem ele, com muito pouco trabalho adicional.
Como cada barbeiro � uma thread, ele tem um thread id, que pode ser obtido
a qualquer momento chamando pthread_self(). Ent�o voc� pode considerar
que todas as chamadas ao monitor tem um argumento impl�cito, que � o
thread id. Assim, o monitor pode fazer o mapeamento entre o thread id e o
indice do barbeiro que ele (monitor) usa internamente para acessar seus
campos vetoriais. Para isso o monitor poderia usar uma tabela de hash. O
�ndice do barbeiro seria alocado na primeira vez que uma "thread barbeiro"
chamasse a fun��o proximoCliente(). Nessa ocasi�o seria inserida na tabela
de hash uma entrada associando o id da thread ao �ndice do barbeiro. As
chamadas subsequentes ao monitor por essa thread efetuariam buscas na
tabela de hash, usando o id da thread como chave para obter o �ndice do
barbeiro.

Precisa mesmo fazer isso neste EP?

N�o. Um argumento adicional como o iBarbeiro � aceit�vel.

Para variar acho que falei demais... Espero que n�o tenha dito nenhuma
bobagem muito grande!

Reverbel


On Mon, 7 May 2001, Tiago wrote:

> No m�dulo da Barbearia temos duas fun��es para os barbeiros:
> 
> void ProximoCliente() {...}
> void CorteTerminado() {...}
> 
> As duas est�o declaradas sem par�metros nem retorno. Que tipo de comunica��o com
> o barbeiro ser� poss�vel?? Posso colocar um par�metro na fun��o, ou o objetivo �
> apenas dar wait? Eu preferia fazer assim:
> 
> ClientePtr ProximoCliente() {...}
> 
> mas
> 
> void ProximoCliente(BarbeiroPtr) {...}
> 
> tamb�m me serve.
> 
> []s, Tiago.
> 
>