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 da conta para a conta . O servidor pode passar por um estado intermedi�rio, em que j� foi subtra�do do saldo de mas ainda n�o foi adicionado ao saldo de , 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.