Ce programme simule des transactions bancaires concurrentes sans mécanismes de protection. Les processus effectuent des transferts entre comptes bancaires stockés dans un fichier de base de données. Cependant, en l'absence de verrouillage, des incohérences peuvent survenir lorsque plusieurs processus accèdent simultanément au fichier.

📋 Description du Programme

Le programme exécute plusieurs processus en parallèle, chacun effectuant un certain nombre de transactions aléatoires entre des comptes bancaires.

Fonctionnalités principales :

Lecture/Écriture de comptes :
Les comptes sont lus et écrits dans un fichier (accounts.db), chaque ligne représentant un compte avec un nom et un solde.
Transactions aléatoires :
Chaque processus effectue des transactions aléatoires entre deux comptes. Le montant transféré est d'au maximum 20 % du solde du compte débité.
Absence de verrouillage :
Aucune protection n'est mise en place pour gérer les accès concurrents au fichier. Cela peut entraîner des écritures corrompues ou des pertes de données.
Calcul du solde total :
Le solde total des comptes est calculé avant et après les transactions pour détecter d'éventuelles incohérences.

⚙️ Compilation et Exécution

Compilation

Utilisez le fichier Makefile pour compiler le programme :

make

Cela génère un exécutable nommé unsecured_transaction.

Exécution

Exécutez le programme en spécifiant :

Le nombre de processus à lancer.
Le nombre de transactions par processus.

Exemple :

./unsecured_transaction 15 30

Ici, 15 processus seront lancés, chacun effectuant 30 transactions.

🛑 Problèmes et Limites

En raison de l'absence de verrouillage, plusieurs problèmes peuvent survenir, en particulier dans des situations d'accès concurrent à la base de données :

1. Incohérences des Données :

Sans mécanismes de synchronisation, deux processus peuvent tenter de lire, modifier et réécrire les données d'un même compte simultanément. Cela entraîne des écritures corrompues, où le solde d'un compte peut être incorrect. Par exemple, deux processus peuvent lire un solde identique, effectuer une transaction basée sur ce solde, puis écrire deux fois ce même solde mis à jour, écrasant ainsi les modifications apportées par l'autre processus.
Exemple d'incohérence :

Le processus 1 lit le solde de Alice (1000€).
Le processus 2 lit également le solde de `Alice (1000€).
Le processus 1 transfère 100€ de Alice à Bob, et écrit 900€ dans le fichier.
Le processus 2 effectue une transaction de 200€ de Alice à Charlie, et écrit 800€ dans le fichier, perdant la modification effectuée par le processus 1.

2. Solde Final Incorrect :

Après l'exécution des transactions, le solde total des comptes peut ne pas correspondre au solde initial en raison des conflits d'écriture. Par exemple, une transaction pourrait ne pas être correctement appliquée à cause de la lecture et de l'écriture concurrentes sur les mêmes données.
Exemple de sortie :

Solde total initial : 10000€
Transaction : Alice -> Bob : 50€
Transaction : Bob -> Alice : 30€
...
Solde total final : 9990€
Le solde final est différent du solde initial...

3. Absence de Contrôle des Transactions :

Sans un mécanisme de verrouillage, il est impossible de garantir qu'une transaction soit complète avant qu'une autre ne soit lancée. Par exemple, un transfert de 100€ entre Alice et Bob peut être partiellement effectué si le programme est interrompu au moment de l'écriture.

📜 Exemple de Résultat

Avant l'exécution

Le fichier accounts.db contient :

...
Diana      7145
Diego      8494
Dominic    4487
Dylan      1157
Easton      429
Eden       5737
Edward     3671
Elaina     4904
...

Compilation et exécution

On compile le programme avec :

make

gcc unsecured_transaction.c -o unsecured_transaction

On exécute avec la commande suivante :

 ./unsecured_transaction 30 40

Après l'exécution

On obtient cette sortie sur la console :

Solde total initial : 400000€
...
Transaction : Alivia -> Kaiden : 14€
Transaction : Arianna -> Barrett : 3€
Transaction : Rosalie -> Connor : 1€
Transaction : Sara -> Arthur : 190€
Transaction : Jude -> Sadie : 41€
...
Solde total final : 4004785€
Le solde final est différent du solde initial...
Tout les processus sont terminés !

🚀 Points à Améliorer

Ajout de verrouillage : Utiliser des mécanismes comme lockf pour sécuriser les accès concurrents au fichier.
Détection de conflits : Identifier et gérer les conflits d'écriture pour éviter les pertes de données.

Pour voir une version améliorée avec des verrous, consultez la section 🔒 Transactions Sécurisées.