Introduction
Après des années à remplir des formulaires et à attendre, tu as enfin obtenu ta licence bancaire. Cela signifie que tu es désormais officiellement autorisé à ouvrir ta propre banque, hourra !
Ta première priorité est de mettre les systèmes informatiques en marche. Après une journée de dur labeur, tu peux déjà ouvrir et fermer des comptes, ainsi que gérer les retraits et les dépôts.
Comme tu n'avais pas envie de te fatiguer à écrire des tests, tu invites quelques amis à venir tester le système. Mais au bout de cinq minutes à peine, l'un de tes amis affirme avoir perdu de l'argent ! Même si tu es convaincu que ton code ne contient aucun bug, tu commences à parcourir les logs pour enquêter.
Ah oui, comme tu le soupçonnais, c'est ton ami qui est en tort ! Il a partagé ses identifiants de test avec un autre ami, et ensemble ils ont conspiré pour faire des dépôts et des retraits sur le même compte en parallèle. Qui ferait une chose pareille ?
Alors que tu soutiens qu'il est physiquement impossible d'accéder à son compte en parallèle, ton ami te fait remarquer d'un air suffisant que les règles bancaires exigent que tu prennes cela en charge. Donc, pas de prise en charge bancaire en parallèle, pas de feu vert pour la mise en production. Avec un soupir, tu prends mentalement note de t'y pencher demain. Cela repoussera ta date de lancement d'au moins un jour de plus, mais bon...
Instructions
Ta tâche consiste à implémenter des comptes bancaires qui prennent en charge l'ouverture et la fermeture, les retraits et les dépôts d'argent.
Comme on peut accéder aux comptes bancaires de bien des manières (internet, téléphones mobiles, prélèvements automatiques), ton logiciel bancaire doit permettre d'accéder aux comptes en toute sécurité depuis plusieurs threads/processus (la terminologie dépend de ton langage de programmation) en parallèle.
Par exemple, il peut y avoir de nombreux dépôts et retraits en parallèle ; tu dois t'assurer qu'il n'y a pas de conditions de concurrence entre le moment où tu lis le solde du compte et celui où tu définis le nouveau solde.
Il doit être possible de fermer un compte ; les opérations sur un compte fermé doivent échouer.
Mise en œuvre
Cet exercice introduit la concurrence.
Pour réussir le dernier test, le mot-clé synchronized ou les verrous peuvent t'être utiles.
Les problèmes liés à l'exécution concurrente de code sont souvent intermittents, car ils dépendent de l'ordre dans lequel le code est exécuté.
C'est pourquoi le dernier test démarre plusieurs threads à plusieurs reprises, afin d'augmenter les chances de détecter un bug.
Cela signifie que ce test devrait échouer si ton implémentation n'est pas sûre vis-à-vis des threads, mais il se peut qu'il réussisse simplement parce qu'aucune tentative de modification concurrente n'a eu lieu.
Il est peu probable que cela se produise plusieurs fois de suite, étant donné que l'ordre dans lequel le code est exécuté devrait varier à chaque fois que tu exécutes le test.
Donc si tu exécutes le dernier test deux ou trois fois et qu'il réussit à chaque fois, tu peux être raisonnablement sûr que ton implémentation est correcte.
