Requisitos da solução

1. O servidor de contas deve ser multithreaded. Para cada conexão TCP recebida, o programa ServContas deve criar ou alocar uma thread que atende o cliente naquela conexão. ``Criar ou alocar uma thread'' significa que o servidor deverá ser capaz de trabalhar tanto no modo thread-per-session como com um thread pool (mais detalhes na próxima seção).

   No arquivo ServidorPrimos.java você encontrará um exemplo de programa que cria uma thread por cliente. O programa ServidorPrimos é um servidor que aceita uma seqüência de números (através de uma conexão TCP) e, para cada número, devolve ao cliente uma string que informa se o número é primo ou não. Para cada conexão recebida ele cria uma thread para lidar com a seqüência de números oriunda desta conexão. O recebimento de uma linha vazia (uma String vazia) indica que o cliente não tem mais números para fornecer ao servidor.

2. As operações saldo, depósito, saque, transferência, info e limite devem ter a propriedade de isolação, ou seja: mesmo que várias operações estejam sendo executadas concorrentemente, o resultado de uma dada operação op é o que seria obtido caso ela fosse a única em execução no servidor e as operações concorrentes com op tivessem rodado antes de op (algumas dessas operações) ou depois de op (as demais operações). Em outras palavras, a propriedade de isolação exige que o resultado da execução de operações concorrentes seja igual ao resultado de alguma execução serial (numa ordem qualquer) dessas mesmas operações.

   Para deixar isso mais concreto, pense num cliente transferindo $X$ da conta $A$ para a conta $B$. O servidor pode passar por um estado intermediário, em que $X$ já foi subtraído do saldo de $A$ mas ainda não foi adicionado ao saldo de $B$, mas esse estado não deve ser visível para nenhum outro cliente! Se, concorrentemente com a transferência, algum cliente pedir (numa só operação) os saldos das duas contas, ele deve receber os dois saldos antes da transferência ou os dois saldos depois da transferência, mas nunca um estado intermediário.

   O programa ServContas deve garantir a isolação das operações usando read/write locks (um lock por conta) e o protocolo two-phase locking (2PL) discutido em classe. Deve ser utilizada a implementação de read/write lock presente no pacote java.util.concurrent.locks.

3. Com o uso de locks, seu servidor pode entrar em deadlock se você não escrevê-lo tomando os devidos cuidados. O ServContas deve utilizar uma estratégia de prevenção de deadlocks baseada na ordenação das aquisições de lock: as operações saldo e transferência, que adquirem mais de um lock de conta, devem adquirir os locks sempre numa mesma ordem (em ordem crescente do número da conta, por exemplo).

4. O ServContas aceita na linha de comando o argumento opcional ``-cozinh'', que desliga a isolação. Com esse argumento, o servidor ignora o protocolo 2PL e roda em ``modo cozinhado'', sem adquirir/liberar locks de contas.

5. O ServContas aceita na linha de comando o argumento opcional ``-suicida'', que desliga a prevenção de deadlock. Com esse argumento, o servidor adquire os locks de contas na ordem em que as contas aparecem nos operações requisitadas pelos clientes. O comando saldo 2 3 1 adquiriria o lock da conta 2, depois o da conta 3 e, por último, o da conta 1.

6. Além do programa ServContas, você deve implementar um conjunto de clientes que façam seu servidor funcionar mal quando chamado com ``-cozinh'' ou com ``-suicida''.
   • Para o ``-cozinh'', implemente um cliente que fica fazendo sucessivas operações de transferência entre duas contas e outro que repete a operação que dá o saldo dessas duas contas até obter um par de saldos que não deveria ser visto.
   • Para o ``-suicida'', implemente um par de clientes que faz o servidor entrar em deadlock.

7. Como o acesso às contas na memória é muito rápido, pode ser difícil fazer os problemas acima se manifestarem. Para facilitar isso, o ServContas pode reconhecer mais um argumento na linha de comando: ``-atraso n'' (onde n é um inteiro positivo) faz com que cada acesso (leitura ou escrita) ao saldo ou ao limite de uma conta leve n milisegundos. Se for chamado com esse argumento, o servidor inserirá um sleep(n) antes de cada acesso ao saldo ou ao limite de uma conta. Junto com o servidor e com os clientes você deverá incluir um relatório contando se foi ou não foi difícil fazer esses problemas aparecerem, a partir de que valor de n eles começam a aparecer, etc.