Conversation
|
o -n está tratado. Testei com 1 e valores para cima, nunca falha (quebra o programa) Tive de mudar muito o programa cliente, principalmente a parte de open() do fifo privado e read() do fifo privado. Da forma como está agora caso não tenha resposta no fifo privado após 5 tentativas quer dizer que não tem nenhuma thread a tratar do seu pedido e então dá FAILD |
O erro que está a dar agora é que há threads com threadid's diferentes mas i's iguais a printar FAILD. A forma de acesso à variável i deve estar quebrada em algum lado, vou tentar tratar disso |
|
Resolvi o número das threads, não podiamos estar a usar o i para printar o numero de cada thread porque é uma variável global, ou seja o i no inicio de uma thread pode ser diferente do i a meio dessa mesma thread porque entretanto outra thread pode tê-lo incrementado |
| } | ||
| else | ||
| { | ||
| // o que é suposto fazer aqui? |
There was a problem hiding this comment.
aqui acho que não precisamos deste else, ele simplesmente fica a correr este ciclo while para se manter aberto até acabar o tempo
There was a problem hiding this comment.
Concordo, quando o if se tornar false fazer cleanup, por isso basta mudar para um while
There was a problem hiding this comment.
Ok estava a pensar e talvez tenha mesmo que ser um if na mesma, porque pode acontecer haver o máximo de threads ativas ao mesmo tempo (pouco provável acho, mas pode acontecer)
There was a problem hiding this comment.
Para chegar a esse else quer dizer que há um pedido mas não existem threads para o atender. Na thread do cliente este vai conseguir excrever no fifo público, fazer o fifo privado e abrir o fifo privado (porque tem NONBLOCK) . Quando tentar ler do fifo é que irá dar erro devido a esta parte :
// Attempts to read from private fifo until there's a response
int try = 0;
while(tmpresult<=0 && try < 5){
if (try != 0)
usleep(100*1000);
tmpresult = read(fd_priv,&receivedMessage,BUFSIZE);
try++;
}
if(tmpresult<=0) {
printRegister(time(NULL), threadn, getpid(), pthread_self(), useTime, -1, FAILD);
if(close(fd_priv)==-1){perror("Client-closePrivateFifo");}
if (unlink(privateFifo)==-1){perror("Error destroying private fifo:");}
pthread_exit(0);
}Que acho que é a estratégia que faz sentido. Tendo em conta que é uma casa de banho, se for feito um pedido e não houver ninguém para "atender" o cliente tem de tentar mais x vezes e voltar mais tarde.
E.G. Se a casa de banho de S.Bento não tivesse torniquete, só a senhora a verificar as senhas. Se chegar lá um gajo que quer mandar o Obama à casa branca e não tiver lá a senhora ele fica um tempo à espera e depois vai embora, para retornar mais tarde ou ir a outro sitio.
Outra estratégia seria guardar o pedido numa fila para assim que houver o thread disponivel tratar desse pedido, mas a fila já está meio implícita nas tentativas que a thread client faz.
Mais 2 coisas:
1º
cada pedido é atendido por um thread, que comunica com o thread cliente e controla o tempo de utilização de um lugar do Quarto de Banho; se não houver lugares disponíveis, espera que haja e prossegue;
Este se não houver lugares diponiveis é dentro de cada thread que se vai verificar, não engloba este problema.
2º
as mensagens trocadas são sempre aos pares:
○ cada pedido terá sempre uma resposta
Vi isto no enunciado e acho que estamos meio lixados. Da forma que está agora como está a fazer a verificação no read por tentativas não está garantido que terá sempre uma resposta. Da forma que está agora serve para caso haja algum erro (de escrita ou leitura dos fifos) que não cause o término do programa de forma inesperada, mas não assegura esta condição :/
There was a problem hiding this comment.
Isso quer dizer que o nthreads é o nthreads em simultâneo? E o cliente tem de esperar que hajam threads disponiveis para o atender? Damn
There was a problem hiding this comment.
nthreads – nº (máximo) de threads a atender pedidos
Yep, em simultâneo não pode haver mais do que nthreads ativas
Quanto ao cliente é que não tenho a certeza. Acho que o objetivo é ter o servidor a tratar de mais trabalho em vez de pôr o cliente a pensar quando pode fazer pedidos ou não.
Acho que o cliente apenas faz pedidos e não se interessa se existem threads para o atender ou não, se houver -> fixe, pedido atendido, se não houver -> FAILD . Acho que não há problema com a parte do "se não houver" porque estão a ser feitos "pedidos" e não "clientes" novos
There was a problem hiding this comment.
Pois faz sentido, os pedidos podem ser da mesma pessoa, o cliente nao tem de saber quando fazer o pedido, simplesmente faz e pronto depois vê se consegue ser atendido ou não, acho q ta bem assim
places to 0 at start
3 participants
Primeiro dar merge a este PR antes de ver este