Apprentissage du langage C#

Dans le paragraphe sur l'échange d'informations entre threads, l'information échangée ne l'était que par deux threads et à des moments bien précis. On avait là un classique passage de paramètres. Il existe d'autres cas où une information est partagée par plusieurs threads qui peuvent vouloir la lire ou la mettre à jour au même moment. Se pose alors le problème de l'intégrité de cette information. Supposons que l'information partagée soit une structure S avec diverses informations I1, I2… In.

• un thread T1 commence à mettre à jour la structure S : il modifie le champ I1 et est interrompu avant d'avoir terminé la mise à jour complète de la structure S
• un thread T2 qui récupère le processeur lit alors la structure S pour prendre des décisions. Il lit une structure dans un état instable : certains champs sont à jour, d'autres pas.

On appelle cette situation, l'accès à une ressource partagée, ici la structure S, et elle est souvent assez délicate à gérer. Prenons l'exemple suivant pour illustrer les problèmes qui peuvent surgir :

• une application va générer n threads, n étant passé en paramètre
• la ressource partagée est un compteur qui devra être incrémenté par chaque thread généré
• à la fin de l'application, la valeur du compteur est affichée. On devrait donc trouver n.

Le programme est le suivant :

using System;
using System.Threading;

namespace Chap8 {
    class Program {

        // variables de classe
        static int cptrThreads = 0;    // compteur de threads

        //main
        public static void Main(string[] args) {
            // mode d'emploi
            const string syntaxe = "pg nbThreads";
            const int nbMaxThreads = 100;

            // vérification nbre d'arguments
            if (args.Length != 1) {
                // erreur
                Console.WriteLine(syntaxe);
                // arrêt
                Environment.Exit(1);
            }
            // vérification qualité de l'argument
            int nbThreads = 0;
            bool erreur = false;
            try {
                nbThreads = int.Parse(args[0]);
                if (nbThreads < 1 || nbThreads > nbMaxThreads)
                    erreur = true;
            } catch {
                // erreur
                erreur = true;
            }
            // erreur ?
            if (erreur) {
                // erreur
                Console.Error.WriteLine("Nombre de threads incorrect (entre 1 et 100)");
                // fin
                Environment.Exit(2);
            }
            // création et génération des threads
            Thread[] threads = new Thread[nbThreads];
            for (int i = 0; i < nbThreads; i++) {
                // création
                threads[i] = new Thread(Incrémente);
                // nommage
                threads[i].Name = "" + i;
                // lancement
                threads[i].Start();
            }//for
            // attente de la fin des threads
            for (int i = 0; i < nbThreads; i++) {
                threads[i].Join();
            }
            // affichage compteur
            Console.WriteLine("Nombre de threads générés : " + cptrThreads);
        }

        public static void Incrémente() {
            // augmente le compteur de threads
            // lecture compteur
            int valeur = cptrThreads;
            // suivi
            Console.WriteLine("A {0:hh:mm:ss}, le thread {1}  a lu la valeur du compteur : {2}", DateTime.Now, Thread.CurrentThread.Name, cptrThreads);
            // attente
            Thread.Sleep(1000);
            // incrémentation compteur
            cptrThreads = valeur + 1;
            // suivi
            Console.WriteLine("A {0:hh:mm:ss}, le thread {1}  a écrit la valeur du compteur : {2}", DateTime.Now, Thread.CurrentThread.Name, cptrThreads);
        }
    }
}

Nous ne nous attarderons pas sur la partie génération de threads déjà étudiée. Intéressons-nous plutôt à la méthode Incrémente, de la ligne 59 utilisée par chaque thread pour incrémenter le compteur statique cptrThreads de la ligne 8.

• ligne 62 : le compteur est lu
• ligne 66 : le thread s'arrête 1 s. Il perd donc le processeur
• ligne 68 : le compteur est incrémenté

L'étape 2 n'est là que pour forcer le thread à perdre le processeur. Celui-ci va être donné à un autre thread. Dans la pratique, rien n'assure qu'un thread ne sera pas interrompu entre le moment où il va lire le compteur et le moment où il va l'incrémenter. Même si on écrit cptrThreads++, donnant ainsi l'illusion d'une instruction unique, le risque existe de perdre le processeur entre le moment où on lit la valeur du compteur et celui on écrit sa valeur incrémentée de 1. En effet, l'opération de haut niveau cptrThreads++ va faire l'objet de plusieurs instructions élémentaires au niveau du processeur. L'étape 2 de sommeil d'une seconde n'est donc là que pour systématiser ce risque.

Les résultats obtenus avec 5 threads sont les suivants :

A 12:00:56, le thread 3  a lu la valeur du compteur : 0
A 12:00:56, le thread 2  a lu la valeur du compteur : 0
A 12:00:56, le thread 1  a lu la valeur du compteur : 0
A 12:00:56, le thread 0  a lu la valeur du compteur : 0
A 12:00:56, le thread 4  a lu la valeur du compteur : 0
A 12:00:57, le thread 3  a écrit la valeur du compteur : 1
A 12:00:57, le thread 2  a écrit la valeur du compteur : 1
A 12:00:57, le thread 1  a écrit la valeur du compteur : 1
A 12:00:57, le thread 0  a écrit la valeur du compteur : 1
A 12:00:57, le thread 4  a écrit la valeur du compteur : 1
Nombre de threads générés : 1

A la lecture de ces résultats, on voit bien ce qui se passe :

• ligne 1 : un premier thread lit le compteur. Il trouve 0. Il s'arrête 1 s donc perd le processeur
• ligne 2 : un second thread prend alors le processeur et lit lui aussi la valeur du compteur. Elle est toujours à 0 puisque le thread précédent ne l'a pas encore incrémentée. Il s'arrête lui aussi 1 s et perd à son tour le processeur.
• lignes 1-5 : en 1 s, les 5 threads ont le temps de passer tous et de lire tous la valeur 0.
• lignes 6-10 : lorsqu'ils vont se réveiller les uns après les autres, ils vont incrémenter la valeur 0 qu'ils ont lue et écrire la valeur 1 dans le compteur, ce que confirme le programme principal (Main) en ligne 11.

D'où vient le problème ? Le second thread a lu une mauvaise valeur du fait que le premier avait été interrompu avant d'avoir terminé son travail qui était de mettre à jour le compteur dans la fenêtre. Cela nous amène à la notion de ressource critique et de section critique d'un programme:

• une ressource critique est une ressource qui ne peut être détenue que par un thread à la fois. Ici la ressource critique est le compteur.
• une section critique d'un programme est une séquence d'instructions dans le flux d'exécution d'un thread au cours de laquelle il accède à une ressource critique. On doit assurer qu'au cours de cette section critique, il est le seul à avoir accès à la ressource.

Dans notre exemple, la section critique est le code situé entre la lecture du compteur et l'écriture de sa nouvelle valeur :

            // lecture compteur
            int valeur = cptrThreads;
            // attente
            Thread.Sleep(1000);
            // incrémentation compteur
cptrThreads = valeur + 1;

Pour exécuter ce code, un thread doit être assuré d'être tout seul. Il peut être interrompu mais pendant cette interruption, un autre thread ne doit pas pouvoir exécuter ce même code. La plate-forme .NET offre divers outils pour assurer l'entrée unitaire dans les sections critiques de code. Nous en voyons quelques-uns maintenant.

La clause lock permet de délimiter une section critique de la façon suivante :

lock(obj){section critique}

obj doit être une référence d'objet visible par tous les threads exécutant la section critique. La clause lock assure qu'un seul thread à la fois exécutera la section critique. L'exemple précédent est réécrit comme suit :

using System;
using System.Threading;

namespace Chap8 {
    class Program2 {

        // variables de classe
        static int cptrThreads = 0;    // compteur de threads
        static object synchro = new object(); // objet de synchronisation

        //main
        public static void Main(string[] args) {
    ...
            // attente de la fin des threads
            Thread.CurrentThread.Name = "Main";
            for (int i = nbThreads - 1; i >= 0; i--) {
                Console.WriteLine("A {0:hh:mm:ss}, le thread {1} attend la fin du thread {2}", DateTime.Now, Thread.CurrentThread.Name, threads[i].Name);
                threads[i].Join();
                Console.WriteLine("A {0:hh:mm:ss}, le thread {1} a été prévenu de la fin du thread {2}", DateTime.Now, Thread.CurrentThread.Name, threads[i].Name);
            }
            // affichage compteur
            Console.WriteLine("Nombre de threads générés : " + cptrThreads);
        }

        public static void Incrémente() {
            // augmente le compteur de threads
            // un accès exclusif au compteur est demandé
            Console.WriteLine("A {0:hh:mm:ss}, le thread {1}  attend l'autorisation d'entrer dans la section critique", DateTime.Now, Thread.CurrentThread.Name);
            lock (synchro) {
                // lecture compteur
                int valeur = cptrThreads;
                // suivi
                Console.WriteLine("A {0:hh:mm:ss}, le thread {1}  a lu la valeur du compteur : {2}", DateTime.Now, Thread.CurrentThread.Name, cptrThreads);
                // attente
                Thread.Sleep(1000);
                // incrémentation compteur
                cptrThreads = valeur + 1;
                // suivi
                Console.WriteLine("A {0:hh:mm:ss}, le thread {1}  a écrit la valeur du compteur : {2}", DateTime.Now, Thread.CurrentThread.Name, cptrThreads);
            }
            Console.WriteLine("A {0:hh:mm:ss}, le thread {1} a quitté la section critique", DateTime.Now, Thread.CurrentThread.Name);
        }
    }
}

• ligne 9 : synchro est l'objet qui va permettre la synchronisation de tous les threads.
• lignes 16-23 : la méthode [Main] attend les threads dans l'ordre inverse de leur création.
• lignes 29-40 : la section critique de la méthode Incrémente a été encadrée par la clause lock.

Les résultats obtenus avec 3 threads sont les suivants :

A 09:37:09, le thread 0 attend l'autorisation d'entrer dans la section critique
A 09:37:09, le thread 0 a lu la valeur du compteur : 0
A 09:37:09, le thread 1 attend l'autorisation d'entrer dans la section critique
A 09:37:09, le thread 2 attend l'autorisation d'entrer dans la section critique
A 09:37:09, le thread Main attend la fin du thread 2
A 09:37:10, le thread 0 a écrit la valeur du compteur : 1
A 09:37:10, le thread 1 a lu la valeur du compteur : 1
A 09:37:10, le thread 0 a quitté la section critique
A 09:37:11, le thread 1 a écrit la valeur du compteur : 2
A 09:37:11, le thread 1 a quitté la section critique
A 09:37:11, le thread 2 a lu la valeur du compteur : 2
A 09:37:12, le thread 2 a écrit la valeur du compteur : 3
A 09:37:12, le thread 2 a quitté la section critique
A 09:37:12, le thread Main a été prévenu de la fin du thread 2
A 09:37:12, le thread Main attend la fin du thread 1
A 09:37:12, le thread Main a été prévenu de la fin du thread 1
A 09:37:12, le thread Main attend la fin du thread 0
A 09:37:12, le thread Main a été prévenu de la fin du thread 0
Nombre de threads générés : 3

• le thread 0 entre le 1er dans la section critique : lignes 1, 2, 6, 8
• les deux autres threads vont être bloqués tant que le thread 0 ne sera pas sorti de la section critique : lignes 3 et 4
• le thread 1 passe ensuite : lignes 7, 9, 10
• le thread 2 passe ensuite : lignes 11, 12, 13
• ligne 14 : le thread Main qui attendait la fin du thread 2 est prévenu
• ligne 15 : le thread Main attend maintenant la fin du thread 1. Celui-ci est déjà terminé. Le thread Main en est prévenu immédiatement, ligne 16.
• lignes 17-18 : le même processus se passe avec le thread 0
• ligne 19 : le nombre de threads est correct

La classe System.Threading.Mutex permet elle aussi de délimiter des sections critiques. Elle diffère de la clause lock en terme de visibilité :

• la clause lock permet de synchroniser des threads d'une même application
• la classe Mutex permet de synchroniser des threads de différentes applications.

Nous utiliserons le constructeur et les méthodes suivants :

Un Mutex M gère l'accès à une ressource partagée R. Un thread demande la ressource R par M.WaitOne() et la rend par M.ReleaseMutex(). Une section critique de code qui ne doit être exécutée que par un seul thread à la fois est une ressource partagée. La synchronisation d'exécution de la section critique peut se faire ainsi :

M.WaitOne();
// le thread est seul à entrer ici
// section critique
....
M.ReleaseMutex();

où M est un objet Mutex. Il ne faut pas oublier de libérer un Mutex devenu inutile afin qu'un autre thread puisse entrer dans la section critique, sinon les threads en attente du Mutex jamais libéré n'auront jamais accès au processeur.

Si nous mettons en pratique sur l'exemple précédent ce que nous venons de voir, notre application devient la suivante :

using System;
using System.Threading;

namespace Chap8 {
    class Program3 {

        // variables de classe
        static int cptrThreads = 0;    // compteur de threads
        static Mutex synchro = new Mutex(); // objet de synchronisation

        //main
        public static void Main(string[] args) {
    ...
        }

        public static void Incrémente() {
....
            synchro.WaitOne();
            try {
...
            } finally {
...
                synchro.ReleaseMutex();
            }
        }
    }
}

• ligne 9 : l'objet de synchronisation des threads est désormais un Mutex.
• ligne 18 : début de la section critique - un seul thread doit y entrer. On se bloque jusqu'à ce que le Mutex synchro soit libre.
• ligne 33 : parce qu'un Mutex doit toujours être libéré, exception ou pas, on gère la section critique avec un try / finally afin de libérer le Mutex dans le finally.
• ligne 23 : le Mutex est libéré une fois la section critique passée.

Les résultats obtenus sont les mêmes que précédemment.

Un objet AutoResetEvent est une barrière ne laissant passer qu'un thread à la fois, comme les deux outils précédents lock et Mutex. On construit un objet AutoResetEvent de la façon suivante :

AutoResetEvent barrière=new AutoresetEvent(bool état);

Le booléen état indique l'état fermé (false) ou ouvert (true) de la barrière. Un thread voulant passer la barrière l'indiquera de la façon suivante :

barrière.WaitOne();

• si la barrière est ouverte, le thread passe et la barrière est refermée derrière lui. Si plusieurs threads attendaient, on est assuré qu'un seul passera.
• si la barrière est fermée, le thread est bloqué. Un autre thread l'ouvrira lorsque le moment sera venu. Ce moment est entièrement dépendant du problème traité. La barrière sera ouverte par l'opération :

barrière.Set();

Il peut arriver qu'un thread veuille fermer une barrière. Il pourra le faire par :

barrière.Reset();

Si dans l'exemple précédent, on remplace l'objet Mutex par un objet de type AutoResetEvent, le code devient le suivant :

using System;
using System.Threading;

namespace Chap8 {
    class Program4 {

        // variables de classe
        static int cptrThreads = 0;    // compteur de threads
        static EventWaitHandle synchro = new AutoResetEvent(false); // objet de synchronisation

        //main
        public static void Main(string[] args) {
....
            // on ouvre la barrière de la section critique
            Console.WriteLine("A {0:hh:mm:ss}, le thread {1} ouvre la barrière de la section critique", DateTime.Now, Thread.CurrentThread.Name);
            synchro.Set();
            // attente de la fin des threads
...
            // affichage compteur
            Console.WriteLine("Nombre de threads générés : " + cptrThreads);
        }

        public static void Incrémente() {
            // augmente le compteur de threads
            // un accès exclusif au compteur est demandé
...
            synchro.WaitOne();
            try {
...
            } finally {
                // on relâche la ressource
...
                synchro.Set();
            }
        }
    }
}

• ligne 9 : la barrière est créée fermée. Elle sera ouverte par le thread Main ligne 16.
• ligne 27 : le thread chargé d'incrémenter le compteur de threads demande l'autorisation d'entrer dans la section critique. Les différents threads vont s'accumuler devant la barrière fermée. Lorque le thread Main va l'ouvrir, l'un des threads en attente va passer.
• ligne 33 : lorsqu'il a terminé son travail, il rouvre la barrière permettant à un autre thread d'entrer.

On obtient des résultats analogues aux précédents.

La classe Interlocked permet de rendre atomique un groupe d'opérations. Dans un groupe d'opérations atomique, soit toutes les opérations sont exécutées par le thread qui exécute le groupe soit aucune. On ne reste pas dans un état ou certaines ont été exécutées et d'autres pas. Les objets de synchronisation lock, Mutex, AutoResetEvent ont toutes pour but de rendre atomique un groupe d'opérations. Ce résultat est obtenu au prix du blocage de threads. La classe Interlocked permet, pour des opérations simples mais assez fréquentes, d'éviter le blocage de threads. La classe Interlocked offre les méthodes statiques suivantes :

La méthode Increment a la signature suivante :

public static int Increment(ref int location);

Elle permet d'incrémenter de 1 le paramètre location. L'opération est garantie atomique.

Notre programme de comptage de threads peut alors être le suivant :

using System;
using System.Threading;

namespace Chap8 {
    class Program5 {

        // variables de classe
        static int cptrThreads = 0;    // compteur de threads

        //main
        public static void Main(string[] args) {
...
        }

        public static void Incrémente() {
            // incrémente le compteur de threads
            Interlocked.Increment(ref cptrThreads);
        }
    }
}

• ligne 17 : le compteur de threads est incrémenté de façon atomique.

Dans nos exemples précédents, une unique ressource était partagée par les différents threads. La situation peut se compliquer s'il y en a plusieurs et qu'elles sont dépendantes les unes des autres. Une situation d'interblocage peut notamment survenir. Cette situation appelée également deadlock est celle dans laquelle deux threads s'attendent mutuellement. Considérons les actions suivantes qui se suivent dans le temps :

• un thread T1 obtient la propriété d'un Mutex M1 pour avoir accès à une ressource partagée R1
• un thread T2 obtient la propriété d'un Mutex M2 pour avoir accès à une ressource partagée R2
• le thread T1 demande le Mutex M2. Il est bloqué.
• le thread T2 demande le Mutex M1. Il est bloqué.

Ici, les threads T1 et T2 s'attendent mutuellement. Ce cas apparaît lorsque des threads ont besoin de deux ressources partagées, la ressource R1 contrôlée par le Mutex M1 et la ressource R2 contrôlée par le Mutex M2. Une solution possible est de demander les deux ressources en même temps à l'aide d'un Mutex unique M. Mais ce n'est pas toujours possible si par exemple cela entraîne une mobilisation longue d'une ressource coûteuse. Une autre solution est qu'un thread ayant M1 et ne pouvant obtenir M2, relâche alors M1 pour éviter l'interblocage.

• On a un tableau dans lequel des threads viennent déposer des données (les écrivains) et d'autres viennent les lire (les lecteurs).
• Les écrivains sont égaux entre-eux mais exclusifs : un seul écrivain à la fois peut déposer ses données dans le tableau.
• Les lecteurs sont égaux entre-eux mais exclusifs : un seul lecteur à la fois peut lire les données déposées dans le tableau.
• Un lecteur ne peut lire les données du tableau que lorsqu'un écrivain en a déposé dedans et un écrivain ne peut déposer de nouvelles données dans le tableau que lorsque celles qui y sont ont été lues par un lecteur.

On peut distinguer deux ressources partagées :

• • le tableau en écriture : un seul écrivain à la fois doit y avoir accès.
  • le tableau en lecture : un seul lecteur à la fois doit y avoir accès.

et un ordre d'utilisation de ces ressources :

• un lecteur doit toujours passer après un écrivain.
• un écrivain doit toujours passer après un lecteur, sauf la 1re fois.

On peut contrôler l'accès à ces deux ressources avec deux barrières de type AutoResetEvent :

• la barrière peutEcrire contrôlera l'accès des écrivains au tableau.
• la barrière peutLire contrôlera l'accès des lecteurs au tableau.
• la barrière peutEcrire sera créée initialement ouverte laissant passer ainsi un 1er écrivain et bloquant tous les autres.
• la barrière peutLire sera créée initialement fermée bloquant tous les lecteurs.
• lorsqu'un écrivain aura terminé son travail, il ouvrira la barrière peutLire pour laisser entrer un lecteur.
• lorsqu'un lecteur aura terminé son travail, il ouvrira la barrière peutEcrire pour laisser entrer un écrivain.

Le programme illustrant cette synchronisation par événements est le suivant :

using System;
using System.Threading;

namespace Chap8 {
    class Program {
        // utilisation de threads lecteurs et écrivains
        // illustre l'utilisation d'événements de synchronisation


        // variables de classe
        static int[] data = new int[3];    // ressource partagée entre threads lecteur et threads écrivain
        static Random objRandom = new Random(DateTime.Now.Second);    // un générateur de nombres aléatoires
        static AutoResetEvent peutLire;    // signale qu'on peut lire le contenu de data
        static AutoResetEvent peutEcrire;    // signale qu'on peut écrire le contenu de data

        //main
        public static void Main(string[] args) {

            // le nbre de threads à générer
            const int nbThreads = 2;

            // initialisation des drapeaux
            peutLire = new AutoResetEvent(false);    // on ne peut pas encore lire
            peutEcrire = new AutoResetEvent(true);    // on peut déjà écrire

            // création des threads lecteurs
            Thread[] lecteurs = new Thread[nbThreads];
            for (int i = 0; i < nbThreads; i++) {
                // création
                lecteurs[i] = new Thread(Lire);
                lecteurs[i].Name = "L" + i.ToString();
                // lancement
                lecteurs[i].Start();
            }

            // création des threads écrivains
            Thread[] écrivains = new Thread[nbThreads];
            for (int i = 0; i < nbThreads; i++) {
                // création
                écrivains[i] = new Thread(Ecrire);
                écrivains[i].Name = "E" + i.ToString();
                // lancement
                écrivains[i].Start();
            }

            //fin de main
            Console.WriteLine("Fin de Main...");
        }

        // lire le contenu du tableau
        public static void Lire() {
...
        }

        // écrire dans le tableau
        public static void Ecrire() {
....
        }
    }
}

• ligne 11 : le tableau data est la ressource partagée entre les threads lecteurs et écrivains. Elle est partagée en lecture par les threads lecteurs, en écriture par les threads écrivains.
• ligne 13 : l'objet peutLire sert à avertir les threads lecteurs qu'ils peuvent lire le tableau data. Il est mis à vrai par le thread écrivain ayant rempli le tableau data. Il est initialisé à false, ligne 23. Il faut qu'un thread écrivain remplisse d'abord le tableau avant de passer l'événement peutLire à vrai.
• ligne 14 : l'objet peutEcrire sert à avertir les threads écrivains qu'ils peuvent écrire dans le tableau data. Il est mis à vrai par le thread lecteur ayant exploité la totalité du tableau data. Il est initialisé à true, ligne 24. En effet, le tableau data est libre en écriture.
• lignes 27-34 : création et lancement des threads lecteurs
• lignes 37-44 : création et lancement des threads écrivains

La méthode Lire exécutée par les threads lecteurs est la suivante :

public static void Lire() {
            // suivi
            Console.WriteLine("Méthode [Lire] démarrée par le thread n° {0}", Thread.CurrentThread.Name);
            // on doit attendre l'autorisation de lecture
            peutLire.WaitOne();
            // lecture tableau
            for (int i = 0; i < data.Length; i++) {
                //attente 1 s
                Thread.Sleep(1000);
                // affichage
                Console.WriteLine("{0:hh:mm:ss} : Le lecteur {1} a lu le nombre {2}", DateTime.Now, Thread.CurrentThread.Name, data[i]);
            }
            // on peut écrire
            peutEcrire.Set();
            // suivi
            Console.WriteLine("Méthode [Lire] terminée par le thread n° {0}", Thread.CurrentThread.Name);
        }

• ligne 5 : on attend qu'un thread écrivain signale que le tableau a été rempli. Lorsque ce signal sera reçu, un seul des threads lecteurs en attente de ce signal pourra passer.
• lignes 7-12 : exploitation du tableau data avec un Sleep au milieu pour forcer le thread à perdre le processeur.
• ligne 14 : indique aux threads écrivains que le tableau a été lu et qu'il peut être rempli de nouveau.

La méthode Ecrire exécutée par les threads écrivains est la suivante :

public static void Ecrire() {
            // suivi
            Console.WriteLine("Méthode [Ecrire] démarrée par le thread n° {0}", Thread.CurrentThread.Name);
            // on doit attendre l'autorisation d'écriture
            peutEcrire.WaitOne();
            // écriture tableau
            for (int i = 0; i < data.Length; i++) {
                //attente 1 s
                Thread.Sleep(1000);
                // affichage
                data[i] = objRandom.Next(0, 1000);
                Console.WriteLine("{0:hh:mm:ss} : L'écrivain {1} a écrit le nombre {2}", DateTime.Now, Thread.CurrentThread.Name, data[i]);
            }
            // on peut lire
            peutLire.Set();
            // suivi
            Console.WriteLine("Méthode [Ecrire] terminée par le thread n° {0}", Thread.CurrentThread.Name);
        }

• ligne 5 : on attend qu'un thread lecteur signale que le tableau a été lu. Lorsque ce signal sera reçu, un seul des threads écrivains en attente de ce signal pourra passer.
• lignes 7-13 : exploitation du tableau data avec un Sleep au milieu pour forcer le thread à perdre le processeur.
• ligne 15 : indique aux threads lecteurs que le tableau a été rempli et qu'il peut être lu de nouveau.

L'exécution donne les résultats suivants :

Méthode [Lire] démarrée par le thread n° L0
Méthode [Lire] démarrée par le thread n° L1
Méthode [Ecrire] démarrée par le thread n° E0
Méthode [Ecrire] démarrée par le thread n° E1
Fin de Main...
02:29:18 : L'écrivain E0 a écrit le nombre 607
02:29:19 : L'écrivain E0 a écrit le nombre 805
02:29:20 : L'écrivain E0 a écrit le nombre 650
Méthode [Ecrire] terminée par le thread n° E0
02:29:21 : Le lecteur L0 a lu le nombre 607
02:29:22 : Le lecteur L0 a lu le nombre 805
02:29:23 : Le lecteur L0 a lu le nombre 650
Méthode [Lire] terminée par le thread n° L0
02:29:24 : L'écrivain E1 a écrit le nombre 186
02:29:25 : L'écrivain E1 a écrit le nombre 881
02:29:26 : L'écrivain E1 a écrit le nombre 415
Méthode [Ecrire] terminée par le thread n° E1
02:29:27 : Le lecteur L1 a lu le nombre 186
02:29:28 : Le lecteur L1 a lu le nombre 881
02:29:29 : Le lecteur L1 a lu le nombre 415
Méthode [Lire] terminée par le thread n° L1

On peut remarquer les points suivants :

• on a bien 1 seul lecteur à la fois, bien que celui-ci perde le processeur dans la section critique Lire
• on a bien 1 seul écrivain à la fois, bien que celui-ci perde le processeur dans la section critique Ecrire
• un lecteur ne lit que lorsqu'il y a quelque chose à lire dans le tableau
• un écrivain n'écrit que lorsque le tableau a été entièrement lu

Dans l'exemple précédent :

• il y a deux ressources partagées à gérer
• pour une ressource donnée, les threads sont égaux.

Lorsque les threads écrivains sont bloqués sur l'instruction peutEcrire.WaitOne, l'un d'entre-eux, n'importe lequel, est débloqué par l'opération peutEcrire.Set. Si l'opération précédente doit ouvrir la barrière à un écrivain en particulier, les choses deviennent plus compliquées.

On peut considérer l'analogie avec un établissement accueillant du public à des guichets où chaque guichet est spécialisé. Lorsque le client arrive, il prend un ticket au distributeur de tickets pour le guichet X puis va s'asseoir. Chaque ticket est numéroté et les clients sont appelés par leur numéro via un haut-parleur. Pendant son attente, le client fait ce qu'il veut. Il peut lire ou somnoler. Il est réveillé à chaque fois par le haut-parleur qui annonce que le n° Y est appelé au guichet X. S'il s'agit de lui, le client se lève et accède au guichet X, sinon il continue ce qu'il faisait.

On peut ici fonctionner de façon analogue. Prenons l'exemple des écrivains :

La classe Monitor permet de mettre en œuvre ce scénario.

Nous décrivons maintenant une construction standard (pattern), proposée dans le chapitre Threading du livre C# 3.0 référencé dans l'introduction de ce document, capable de résoudre les problèmes de barrière avec condition d'entrée.

• Tout d'abord, les threads qui se partagent une ressource (le guichet…) y accèdent via un objet que nous appellerons un jeton. Pour ouvrir la barrière qui mène au guichet, il faut avoir le jeton pour l'ouvrir et il n'y a qu'un seul jeton. Les threads doivent donc se passer le jeton entre-eux.

object jeton=new object();

• Pour aller au guichet, les threads demandent tout d'abord le jeton :

Monitor.Enter(jeton);

Si le jeton est libre, il est donné au thread ayant exécuté l'opération précédente, sinon le thread est mis en attente du jeton.

• Si l'accès au guichet se fait de façon non ordonnée, c.a.d. dans le cas où la personne qui entre n'importe pas, l'opération précédente est suffisante. Le thread ayant le jeton va au guichet. Si l'accès se fait de façon ordonnée, le thread qui a le jeton vérifie qu'il remplit la condition pour aller au guichet :

while (! jeNeSuisPasCeluiQuiEstAttendu) {Monitor.Wait(jeton);}

Si le thread n'est pas celui qui est attendu au guichet, il laisse son tour en redonnant le jeton. Il passe dans un état bloqué. Il sera réveillé dès que le jeton redeviendra disponible pour lui. Il vérifiera alors de nouveau s'il vérifie la condition pour aller au guichet. L'opération Monitor.Wait(jeton) qui relâche le jeton ne peut être faite que si le thread est propriétaire du jeton. Si ce n'est pas le cas, une exception est lancée.

• Le thread qui vérifie la condition pour aller au guichet y va :

// travail au guichet
....

Avant de quitter le guichet, le thread doit rendre son jeton, sinon les threads bloqués en attente de celui-ci le resteront indéfiniment. Il y a deux situations différentes :

• la première situation est celle où le thread ayant le jeton est également celui qui signale aux threads en attente du jeton que celui-ci est libre. Il le fera de la façon suivante :

// travail au guichet
....
// modification condition d'accès au guichet
...
// réveil des threads en attente du jeton
Monitor.PulseAll(jeton);
// libération du jeton
Monitor.Exit(jeton);

Ligne 6, il réveille les threads en attente du jeton. Ce réveil signifie qu'ils deviennent éligibles pour recevoir le jeton. Cela ne veut pas dire qu'ils le reçoivent immédiatement. Ligne 8, le jeton est libéré. Tous les threads éligibles vont recevoir tour à tour le jeton, de façon indéterministe. Cela va leur donner l'occasion de vérifier de nouveau s'ils vérifient la condition d'accès. Le thread ayant libéré le jeton a modifié cette condition ligne 4 afin de permettre à un nouveau thread d'entrer. Le premier qui la vérifie garde le jeton et va au guichet à son tour.

• la seconde situation est celle où le thread ayant le jeton n'est pas celui qui doit signaler aux threads en attente du jeton que celui-ci est libre. Il doit néanmoins le libérer parce que le thread chargé d'envoyer ce signal doit être détenteur du jeton. Il le fera par l'opération :

Monitor.Exit(jeton);

Le jeton est désormais disponible, mais les threads qui l'attendent (ils ont fait une opération Wait(jeton)) n'en sont pas avertis. Cette tâche est confiée à un autre thread qui à un moment donné exécutera un code similaire au suivant :

// acquisition jeton
Monitor.Enter(jeton);
// modification condition d'accès au guichet
....
// réveil des threads en attente du jeton
Monitor.PulseAll(jeton);
// libération du jeton
Monitor.Exit(jeton);

Au final, la construction standard proposée dans le chapitre Threading du livre C# 3.0 est la suivante :

• définir le jeton d'accès au guichet :

object jeton=new object();

• demander l'accès au guichet :

lock(jeton){
    while (! jeNeSuisPasCeluiQuiEstAttendu) 
        Monitor.Wait(jeton);
}
// passage au guichet
...

lock(jeton){...}

est équivalent à

Monitor.Enter(jeton);
try{...} finally{Monitor.Exit(jeton);}

On notera que dans ce schéma le jeton est relâché immédiatement, dès que la barrière est passée. Un autre thread peut alors tester la condition d'accès. La construction précédente laisse donc entrer tous les threads vérifiant la condition d'accès. Si ce n'est pas ce qui est désiré, on pourra écrire :

lock(jeton){
    while (! jeNeSuisPasCeluiQuiEstAttendu) 
        Monitor.Wait(jeton);
    // passage au guichet
    ...
}

où le jeton n'est relâché qu'après le passage au guichet.

• modifier la condition d'accès au guichet et en avertir les autres threads

lock(jeton){
    // modifier la condition d'accès au guichet
    ...
    // en avertir les threads en attente du jeton
    Monitor.PulseAll(jeton);
}

Ci-dessus, la condition d'accès ne peut être modifiée que par le thread ayant le jeton. On pourra aussi écrire :

    // modifier la condition d'accès au guichet
    ...
    // en avertir les threads en attente du jeton
    Monitor.PulseAll(jeton);
    // libérer le jeton
    Monitor.Exit(jeton);

si le thread a déjà le jeton.

Muni de ces informations, nous pouvons réécrire l'application lecteurs / écrivains en fixant un ordre des lecteurs et des écrivains pour l'accès à leurs guichets respectifs. Le code est le suivant :

using System;
using System.Threading;

namespace Chap8 {
    class Program2 {
        // utilisation de threads lecteurs et écrivains
        // illustre l'utilisation d'événements de synchronisation


        // variables de classe
        static int[] data = new int[3];            // ressource partagée entre threads lecteur et threads écrivain
        static Random objRandom = new Random(DateTime.Now.Second);    // un générateur de nombres aléatoires
        static object peutLire = new object();        // signale qu'on peut lire le contenu de data
        static object peutEcrire = new object();    // signale qu'on peut écrire le contenu de data
        static bool lectureAutorisée = false;    // pour autoriser la lecture du tableau
        static bool écritureAutorisée = false;    // pour autoriser l'écriture dans le tableau
        static string[] ordreLecture;    // fixe l'ordre des lecteurs
        static string[] ordreEcriture;    // fixe l'ordre des écrivains
        static int lecteurSuivant = 0;    // indique le n° du lecteur suivant
        static int écrivainSuivant = 0;    // indique le n° de l'écrivain suivant

        //main
        public static void Main(string[] args) {

            // le nbre de threads à générer
            const int nbThreads = 5;

            // création des threads lecteurs
            Thread[] lecteurs = new Thread[nbThreads];
            for (int i = 0; i < nbThreads; i++) {
                // création
                lecteurs[i] = new Thread(Lire);
                lecteurs[i].Name = "L" + i.ToString();
                // lancement
                lecteurs[i].Start();
            }

            // création de l'ordre de lecture
            ordreLecture = new string[nbThreads];
            for (int i = 0; i < nbThreads; i++) {
                ordreLecture[i] = lecteurs[nbThreads - i - 1].Name;
                Console.WriteLine("Le lecteur {0} est en position {1}", ordreLecture[i], i);
            }

            // création des threads écrivains
            Thread[] écrivains = new Thread[nbThreads];
            for (int i = 0; i < nbThreads; i++) {
                // création
                écrivains[i] = new Thread(Ecrire);
                écrivains[i].Name = "E" + i.ToString();
                // lancement
                écrivains[i].Start();
            }

            // création de l'ordre d'écriture
            ordreEcriture = new string[nbThreads];
            for (int i = 0; i < nbThreads; i++) {
                ordreEcriture[i] = écrivains[i].Name;
                Console.WriteLine("L'écrivain {0} est en position {1}", ordreEcriture[i], i);
            }

            // autorisation d'écriture
            lock (peutEcrire) {
               écritureAutorisée = true;
                Monitor.Pulse(peutEcrire);
            }


            //fin de main
            Console.WriteLine("Fin de Main...");
        }

        // lire le contenu du tableau
        public static void Lire() {
...
        }

        // écrire dans le tableau
        public static void Ecrire() {
...
        }
    }
}

L'accès au guichet de lecture est conditionné par les éléments suivants :

• ligne 13 : le jeton peutLire
• ligne 15 : le booléen lectureAutorisée
• ligne 17 : le tableau ordonné des lecteurs. Les lecteurs vont au guichet de lecture dans l'ordre de ce tableau qui contient leurs noms.
• ligne 19 : lecteurSuivant indique le n° du prochain lecteur autorisé à aller au guichet.

L'accès au guichet d'écriture est conditionné par les éléments suivants :

• ligne 14 : le jeton peutEcrire
• ligne 16 : le booléen écritureAutorisée
• ligne 18 : le tableau ordonné des écrivains. Les écrivains vont au guichet d'écriture dans l'ordre de ce tableau qui contient leurs noms.
• ligne 20 : écrivainSuivant indique le n° du prochain écrivain autorisé à aller au guichet.

Les autres éléments du code sont les suivants :

• lignes 29-36 : création et lancement des threads lecteurs. Ils seront tous bloqués car la lecture n'est pas autorisée (ligne 15).
• lignes 39-43 : leur ordre de passage au guichet se fera dans l'ordre inverse de leur création.
• lignes 46-53 : création et lancement des threads érivains. Ils seront tous bloqués car l'écriture n'est pas autorisée (ligne 16).
• lignes 56-60 : leur ordre de passage au guichet se fera dans l'ordre de leur création.
• ligne 64 : on autorise l'écriture
• ligne 65 : on avertit les écrivains que quelque chose a changé.

La méthode Lire est la suivante :

        public static void Lire() {
            // suivi
            Console.WriteLine("Méthode [Lire] démarrée par le thread n° {0}", Thread.CurrentThread.Name);
            // on doit attendre l'autorisation de lecture
            lock (peutLire) {
                while (!lectureAutorisée || ordreLecture[lecteurSuivant] != Thread.CurrentThread.Name) {
                    Monitor.Wait(peutLire);
                }
                // lecture tableau
                for (int i = 0; i < data.Length; i++) {
                    //attente 1 s
                    Thread.Sleep(1000);
                    // affichage
                    Console.WriteLine("{0:hh:mm:ss} : Le lecteur {1} a lu le nombre {2}", DateTime.Now, Thread.CurrentThread.Name, data[i]);
                }
                // lecteur suivant
                lectureAutorisée = false;
                lecteurSuivant++;
                // on prévient les écrivains qu'ils peuvent écrire
                lock (peutEcrire) {
                    écritureAutorisée = true;
                    Monitor.PulseAll(peutEcrire);
                }

                // suivi
                Console.WriteLine("Méthode [Lire] terminée par le thread n° {0}", Thread.CurrentThread.Name);
            }
}

• l'ensemble de l'accès au guichet est contrôlé par le lock des lignes 5-27. Le lecteur qui récupère le jeton le garde pendant tout son passage au guichet
• lignes 6-8 : un lecteur ayant acquis le jeton ligne 5 le relâche si la lecture n'est pas autorisée ou si ce n'est pas à son tour de passer.
• lignes 10-15 : passage au guichet (exploitation du tableau)
• lignes 17-18 : le thread change les conditions d'accès au guichet de lecture. On notera qu'il a toujours le jeton de lecture et que ces modifications ne peuvent pas encore permettre à un lecteur de passer.
• lignes 20-23 : le thread change les conditions d'accès au guichet d'écriture et prévient tous les écrivains en attente que quelque chose a changé.
• ligne 27 : le lock se termine, le jeton peutLire est relâché. Un thread de lecture pourrait alors l'acquérir ligne 5 mais il ne passerait pas la condition d'accès puisque le booléen lectureAutorisée est à faux. Par ailleurs, tous les threads qui sont en attente du jeton peutLire le restent car l'opération PulseAll(peutLire) n'a pas encore eu lieu.

La méthode Ecrire est la suivante :

        public static void Ecrire() {
            // suivi
            Console.WriteLine("Méthode [Ecrire] démarrée par le thread n° {0}", Thread.CurrentThread.Name);
            // on doit attendre l'autorisation d'écriture
            lock (peutEcrire) {
                while (!écritureAutorisée || ordreEcriture[écrivainSuivant] != Thread.CurrentThread.Name) {
                    Monitor.Wait(peutEcrire);
                }
                // écriture tableau
                for (int i = 0; i < data.Length; i++) {
                    //attente 1 s
                    Thread.Sleep(1000);
                    // affichage
                    data[i] = objRandom.Next(0, 1000);
                    Console.WriteLine("{0:hh:mm:ss} : L'écrivain {1} a écrit le nombre {2}", DateTime.Now, Thread.CurrentThread.Name, data[i]);
                }
                // écrivain suivant
                écritureAutorisée = false;
                écrivainSuivant++;
                // on réveille les lecteurs en attente du jeton peutLire
                lock (peutLire) {
                    lectureAutorisée = true;
                    Monitor.PulseAll(peutLire);
                }
                // suivi
                Console.WriteLine("Méthode [Ecrire] terminée par le thread n° {0}", Thread.CurrentThread.Name);
            }
}

• l'ensemble de l'accès au guichet d'écriture est contrôlé par le lock des lignes 5-27. L'écrivain qui récupère le jeton le garde pendant tout son passage au guichet
• lignes 6-8 : un écrivain ayant acquis le jeton ligne 5 le relâche si l'écriture n'est pas autorisée ou si ce n'est pas à son tour de passer.
• lignes 10-16 : passage au guichet (exploitation du tableau)
• lignes 18-19 : le thread change les conditions d'accès au guichet d'écriture. On notera qu'il a toujours le jeton d'écriture et que ces modifications ne peuvent pas encore permettre à un écrivain de passer.
• lignes 21-24 : le thread change les conditions d'accès au guichet de lecture et prévient tous les lecteurs en attente que quelque chose a changé.
• ligne 27 : le lock se termine, le jeton peutEcrire est relâché. Un thread d'écriture pourrait alors l'acquérir ligne 5 mais il ne passerait pas la condition d'accès puisque le booléen écritureAutorisée est à faux. Par ailleurs, tous les threads qui sont en attente du jeton peutEcrire le restent dans l'attente d'une nouvelle opération PulseAll(peutEcrire).

Un exemple d'exécution est le suivant :

Méthode [Lire] démarrée par le thread n° L0
Méthode [Lire] démarrée par le thread n° L2
Méthode [Lire] démarrée par le thread n° L1
Le lecteur L2 est en position 0
Le lecteur L1 est en position 1
Le lecteur L0 est en position 2
Méthode [Ecrire] démarrée par le thread n° E0
Méthode [Ecrire] démarrée par le thread n° E1
L'écrivain E0 est en position 0
L'écrivain E1 est en position 1
L'écrivain E2 est en position 2
Fin de Main...
Méthode [Ecrire] démarrée par le thread n° E2
12:09:05 : L'écrivain E0 a écrit le nombre 815
12:09:06 : L'écrivain E0 a écrit le nombre 990
12:09:07 : L'écrivain E0 a écrit le nombre 563
Méthode [Ecrire] terminée par le thread n° E0
12:09:08 : Le lecteur L2 a lu le nombre 815
12:09:09 : Le lecteur L2 a lu le nombre 990
12:09:10 : Le lecteur L2 a lu le nombre 563
Méthode [Lire] terminée par le thread n° L2
12:09:11 : L'écrivain E1 a écrit le nombre 411
12:09:12 : L'écrivain E1 a écrit le nombre 11
12:09:13 : L'écrivain E1 a écrit le nombre 54
Méthode [Ecrire] terminée par le thread n° E1
12:09:14 : Le lecteur L1 a lu le nombre 411
12:09:15 : Le lecteur L1 a lu le nombre 11
12:09:16 : Le lecteur L1 a lu le nombre 54
Méthode [Lire] terminée par le thread n° L1
12:09:17 : L'écrivain E2 a écrit le nombre 698
12:09:18 : L'écrivain E2 a écrit le nombre 448
12:09:19 : L'écrivain E2 a écrit le nombre 472
Méthode [Ecrire] terminée par le thread n° E2
12:09:20 : Le lecteur L0 a lu le nombre 698
12:09:21 : Le lecteur L0 a lu le nombre 448
12:09:22 : Le lecteur L0 a lu le nombre 472
Méthode [Lire] terminée par le thread n° L0

La classe BackgroundWorker appartient à l'espace de noms [System.ComponentModel]. Elle s'utilise comme un thread mais présente des particularités qui peuvent la rendre, dans certains cas, plus intéressante que la classe [Thread] :

• elle émet les événements suivants :
• DoWork : un thread a demandé l'exécution du BackgroundWorker
• ProgressChanged : l'objet BackgroundWorker a exécuté la méthode ReportProgress. Celle-ci sert à donner un pourcentage d'exécution.
• RunWorkerCompleted : l'objet BackgroundWorker a terminé son travail. Il a pu le terminer normalement ou sur annulation ou exception.

Ces événements rendent le BackgroundWorker utile dans les interfaces graphiques : une tâche longue sera confiée à un BackgroundWorker qui pourra rendre compte de son avancement avec l'événement ProgressChanged et sa fin avec l'événement RunWorkerCompleted. Le travail à effectuer par le BackgroundWorker sera gfait par une méthode qui aura été associée à l'événement DoWork.

• il est possible de demander son annulation. Dans une interface graphique, une tâche longue pourra ainsi être annulée par l'utilisateur.
• les objets BackgroundWorker appartiennent à un pool et sont recyclés selon les besoins. Une application qui a besoin d'un objet BackgroundWorker l'obtiendra auprès du pool qui lui donnera un thread déjà existant mais inutilisé. Le fait de recycler ainsi les threads plutôt que de créer à chaque fois un thread neuf, améliore les performances.

Nous utilisons cet outil sur l'application précédente dans le cas où l'accès au guichet est non contrôlé :

using System;
using System.Threading;
using System.ComponentModel;

namespace Chap8 {
    class Program2 {
        // utilisation de threads lecteurs et écrivains
        // illustre l'utilisation simultanée de ressources partagées et de synchronisation

        // variables de classe
        const int nbThreads = 2;                    // nbre de threads au total
        static int nbLecteursTerminés = 0;        // nbre de threads terminés
        static int[] data = new int[5];            // tableau partagé entre threads lecteur et threads écrivain
        static object appli;                            // synchronise l'accès au nbre de threads terminés
        static Random objRandom = new Random(DateTime.Now.Second);    // un générateur de nombres aléatoires
        static AutoResetEvent peutLire;        // signale qu'on peut lire le contenu du tableau
        static AutoResetEvent peutEcrire;        // signale qu'on peut écrire dans le tableau
        static AutoResetEvent finLecteurs;    // signale la fin des lecteurs

        //main
        public static void Main(string[] args) {

            // on donne un nom au thread
            Thread.CurrentThread.Name = "Main";

            // initialisation des drapeaux
            peutLire = new AutoResetEvent(false);        // on ne peut pas encore lire
            peutEcrire = new AutoResetEvent(true);    // on peut déjà écrire
            finLecteurs = new AutoResetEvent(false);    // appli non terminée

            // synchronise l'accès au compteur de threads terminés
            appli = new object();                

            // création des threads lecteurs
            MyBackgroundWorker[] lecteurs = new MyBackgroundWorker[nbThreads];
            for (int i = 0; i < nbThreads; i++) {
                // création
                lecteurs[i] = new MyBackgroundWorker();
                lecteurs[i].Numéro = "L" + i;
                lecteurs[i].DoWork += Lire;
                lecteurs[i].RunWorkerCompleted += EndLecteur;
                // lancement
                lecteurs[i].RunWorkerAsync();
            }

            // création des threads écrivains
            MyBackgroundWorker[] écrivains = new MyBackgroundWorker[nbThreads];
            for (int i = 0; i < nbThreads; i++) {
                // création
                écrivains[i] = new MyBackgroundWorker();
                écrivains[i].Numéro = "E" + i;
                écrivains[i].DoWork += Ecrire;
                // lancement
                écrivains[i].RunWorkerAsync();
            }

            // attente de la fin de tous les threads
            finLecteurs.WaitOne();
            //fin de main
            Console.WriteLine("Fin de Main...");
        }

        public static void EndLecteur(object sender, RunWorkerCompletedEventArgs infos) {
...
        }

        // lire le contenu du tableau
        public static void Lire(object sender, DoWorkEventArgs infos) {
...
        }

        // écrire dans le tableau
        public static void Ecrire(object sender, DoWorkEventArgs infos) {
...
        }
    }

    // thread
    internal class MyBackgroundWorker : BackgroundWorker {
        // informations diverses
        public string Numéro { get; set; }
    }

}

Nous ne détaillons que les changements :

• la classe Thread est remplacée par la classe MyBackgroundWorker des lignes 79-82. La classe BackgroundWorker a été dérivée afin de donner un numéro au thread. On aurait pu procéder différemment en passant un objet à la méthode RunWorkerAsync des lignes 43 et 54, objet contenant le n° du thread.
• ligne 58 : la méthode Main se termine après que tous les threads lecteurs ont fait leur travail. Pour cela, ligne 12, le compteur nbLecteursTerminés compte le nombre de threads lecteurs ayant terminé leur travail. Ce compteur est incrémenté par la méthode EndLecteur des lignes 63-65 qui est exécutée à chaque fois qu'un thread lecteur se termine. C'est cette procédure qui contrôle l'événement AutoResetEvent finLecteurs de la ligne 18 sur lequel se synchronise, ligne 59, la méthode Main.
• ligne 16 : parce que plusieurs threads lecteurs peuvent vouloir incrémenter en même temps le compteur nbLecteursTerminés, un accès exclusif à celui-ci est assuré par l'objet de synchronisation appli. Ce cas est improbable mais théoriquement possible.
• lignes 35-44 : création des threads lecteurs
• ligne 38 : création du thread de type MyBackgroundWorker
• ligne 39 : on lui donne un N°
• ligne 40 : on lui assigne la méthode Lire à exécuter
• ligne 41 : la méthode EndLecteur sera exécutée après la fin du thread
• ligne 43 : le thread est lancé
• lignes 47-55 : création des threads écrivains
• ligne 50 : création du thread de type MyBackgroundWorker
• ligne 51 : on lui donne un N°
• ligne 52 : on lui assigne la méthode Ecrire à exécuter
• ligne 54 : le thread est lancé

Les méthodes Lire et Ecrire restent inchangées. La méthode EndLecteur est exécutée à la fin de chaque thread lecteur. Son code est le suivant :

        public static void EndLecteur(object sender, RunWorkerCompletedEventArgs infos) {
            // incrémentation nbre de lecteurs terminés
            lock (appli) {
                nbLecteursTerminés++;
                if (nbLecteursTerminés == nbThreads)
                    finLecteurs.Set();
            }
}

Le rôle de la méthode EndLecteur est d'avertir la méthode Main que tous les lecteurs ont fait leur travail.

• ligne 4 : le compteur nbLecteursTerminés est incrémenté.
• lignes 5-6 : si tous les lecteurs ont fait leur travail, alors l'événement finLecteurs est positionné à vrai afin de prévenir la méthode Main qui attend cet événement.
• parce que la procédure EndLecteur est exécutée par plusieurs threads, la section critique précédente est protégée par la clause lock de la ligne 3.

L'exécution donne des résultats analogues à ceux de la version utilisant des threads.

Le code suivant illustre d'autres points de la classe BackgroundWorker :

• la possibilité d'annuler la tâche
• la remontée d'une exception lancée dans la tâche
• le passage d'un paramètre d'E/S à la tâche

using System;
using System.Threading;
using System.ComponentModel;

namespace Chap8 {
    class Program3 {

        // threads
        static BackgroundWorker[] tâches = new BackgroundWorker[5];

        public static void Main() {
            // init Thread courant
            Thread main = Thread.CurrentThread;
            // on fixe un nom au Thread
            main.Name = "Main";

            // création de threads
            for (int i = 0; i < tâches.Length; i++) {
                // on crée le thread n° i
                tâches[i] = new BackgroundWorker();
                // on l'initialise
                tâches[i].DoWork += Sleep;
                tâches[i].RunWorkerCompleted += End;
                tâches[i].WorkerSupportsCancellation = true;
                // on le lance
                tâches[i].RunWorkerAsync(new Data { Numéro = i, Début = DateTime.Now, Durée = i + 1 });
            }
            // on annule le dernier thread
            tâches[4].CancelAsync();

            // fin de main
            Console.WriteLine("Fin du thread {0}, tapez [entrée] pour terminer...", main.Name);
            Console.ReadLine();
            return;
        }

        public static void Sleep(object sender, DoWorkEventArgs infos) {
...
        }

        public static void End(object sender, RunWorkerCompletedEventArgs infos) {
...
        }

        internal class Data {
            // informations diverses
            public int Numéro { get; set; }
            public DateTime Début { get; set; }
            public int Durée { get; set; }
            public DateTime Fin { get; set; }
        }
    }
}

• ligne 9 : le tableau de BackgroundWorker
• lignes 18-27 : création des threads
• ligne 20 : création du thread
• ligne 22 : le thread exécutera la méthode Sleep des lignes 39-41
• ligne 23 : la méthode End des lignes 43-45 sera exécutée à la fin du thread
• ligne 24 : le thread pourra être annulé
• ligne 26 : le thread est lancé avec un paramètre de type [Data], défini lignes 49-52. Cet objet a les champs suivants :
• Numéro (entrée) : n° du thread
• Début (entrée) : heure de début d'exécution du thread
• Durée (entrée) : durée d'exécution du Sleep
• Fin (sortie) : fin d'exécution du thread
• ligne 29 : le thread n° 4 est annulé

Tous les threads exécutent la méthode Sleep suivante :

        public static void Sleep(object sender, DoWorkEventArgs infos) {
            // on exploite le paramètre infos
            Data data = (Data)infos.Argument;
            // exception pour la tâche n° 3
            if (data.Numéro == 3) {
                throw new Exception("test....");
            }
            // mise en sommeil pendant Durée secondes avec un arrêt ttes les secondes
            for (int i = 1; i <= data.Durée && !tâches[data.Numéro].CancellationPending; i++) {
                // attente d'1 seconde
                Thread.Sleep(1000);
            }
            // fin d'exécution
            data.Fin = DateTime.Now;
            // on initialise le résultat
            infos.Result = data;
            infos.Cancel = tâches[data.Numéro].CancellationPending;
}

• ligne 1 : la méthode Sleep a la signature standard des gestionnaires d'événements. Elle reçoit deux paramètres :
• sender : l'émetteur de l'événement, ici le BackgroundWorker qui exécute la méthode
• infos : de type DoWorkEventArgs qui donne des informations sur l'événement DoWork. Ce paramètre sert aussi bien à transmettre des informations au thread qu'à récupérer ses résultats.
• ligne 3 : le paramètre passé à la méthode RunWorkerAsync de la tâche est retrouvé dans la propriété infos.Argument.
• lignes 5-7 : on lance une exception pour la tâche n° 3
• lignes 9-12 : le thread "dort" Durée secondes par tranches d'une seconde afin de permettre le test d'annulation de la ligne 9. Cela simule un travail de longue durée au cours duquel le thread vérifierait régulièrement s'il existe une demande d'annulation. Pour indiquer qu'il a été annulé, le thread doit mettre la propriété infos.Cancel à vrai (ligne 17).
• ligne 16 : le thread peut rendre un résultat au thread qui l'a lancé. Il place ce résultat dans infos.Result.

Une fois terminés, les threads exécutent la méthode End suivante :

public static void End(object sender, RunWorkerCompletedEventArgs infos) {
            // on exploite le paramètre infos pour afficher le résultat de l'exécution
            // exception ?
            if (infos.Error != null) {
                Console.WriteLine("Le thread {1} a rencontré l'erreur suivante : {0}", infos.Error.Message, sender);
            } else
                if (!infos.Cancelled) {
                    Data data = (Data)infos.Result;
                    Console.WriteLine("Thread {0} terminé : début {1:hh:mm:ss}, durée programmée {2} s, fin {3:hh:mm:ss}, durée effective {4}",
                    data.Numéro, data.Début, data.Durée, data.Fin, (data.Fin - data.Début));
                } else {
                    Console.WriteLine("Thread {0} annulé", sender);
                }
        }

• ligne 1 : la méthode End a la signature standard des gestionnaires d'événements. Elle reçoit deux paramètres :
• sender : l'émetteur de l'événement, ici le BackgroundWorker qui exécute la méthode
• infos : de type RunWorkerCompletedEventArgs qui donne des informations sur l'événement RunWorkerCompleted.
• ligne 4 : le champ infos.Error de type Exception est renseigné seulement si une exception s'est produite.
• ligne 7 : le champ infos.Cancelled de type booléen à la valeur true si le thread a été annulé.
• ligne 8 : s'il y a pas eu exception ou annulation, alors infos.Result est le résultat du thread exécuté. Utiliser ce résultat s'il y a eu annulation du thread ou si le thread a lancé une exception, provoque une exception. Ainsi lignes 5 et 13, on n'est pas capables d'afficher le n° du thread annulé ou qui a lancé une exception car ce n° est dans infos.Result. Ce problème peut être contourné en dérivant la classe BackgroundWorker pour y mettre les informations à échanger entre le thread appelant et le thread appelé comme il a été fait dans l'exemple précédent. On utilise alors l'argument sender qui représente le BackgroundWorker au lieu de l'argument infos.

Les résultats d'exécution sont les suivants :

Fin du thread Main. Laissez les autres threads se terminer puis tapez [entrée] pour terminer...
Thread 0 terminé : début 05:19:46, durée programmée 1 s, fin 05:19:47, durée effective 00:00:01
Le thread System.ComponentModel.BackgroundWorker a rencontré l'erreur suivante : test....
Thread System.ComponentModel.BackgroundWorker annulé
Thread 1 terminé : début 05:19:46, durée programmée 2 s, fin 05:19:49, durée effective 00:00:03
Thread 2 terminé : début 05:19:46, durée programmée 3 s, fin 05:19:50, durée effective 00:00:04

Considérons une application à trois couches :

Supposons que l'application soit multiutilisateurs, une application web par exemple. Chaque utilisateur est servi par un thread qui lui est dédié. La vie du thread est la suivante :

• le thread est créé ou demandé à un pool de threads pour satisfaire une demande d'un utilisateur
• si cette demande nécessite des données, le thread va exécuter une méthode de la couche [ui] qui va appeler une méthode de la couche [metier] qui va à son tour appeler une méthode de la couche [dao].
• le thread rend la réponse à l'utilisateur. Il disparaît ensuite ou il est recyclé dans un pool de threads.

Dans l'opération 2, il peut être intéressant que le thread ait des données qui lui soient propres, c.a.d. non partagées avec les autres threads. Ces données pourraient par exemple appartenir à l'utilisateur particulier que le thread sert. Ces données pourraient alors être utilisées dans les différentes couches [ui, metier, dao].

La classe Thread permet ce scénario grâce à une sorte de dictionnaire privé où les clés seraient de type LocalDataStoreSlot :

Un modèle d'utilisation pourrait être le suivant :

• pour créer un couple (clé,valeur) associé au thread courant :

Thread.SetData(Thread.GetNamedDataSlot("clé"),valeur);

• pour récupérer la valeur associée à clé :

Thread.GetData(Thread.GetNamedDataSlot("clé"));

Considérons l'application à trois couches suivantes :

Supposons que la couche [dao] gère une base d'articles et que son interface soit initialement la suivante :

using System.Collections.Generic;

namespace Chap8 {
    public interface IDao {
        int InsertArticle(Article article);
        List<Article> GetAllArticles();
        void DeleteAllArticles();
    }
}

• ligne 5 : pour insérer un article dans la base
• ligne 6 : pour récupérer tous les articles de la base
• ligne 7 : pour supprimer tous les articles de la base

Ultérieurement, apparaît le besoin d'une méthode pour insérer un tableau d'articles à l'aide d'une transaction parce qu'on souhaite fonctionner en tout ou rien : soit tous les articles sont insérés soit aucun. On peut alors modifier l'interface pour intégrer ce nouveau besoin :

using System.Collections.Generic;

namespace Chap8 {
    public interface IDao {
        int InsertArticle(Article article);
        void insertArticles(Article[] articles);
        List<Article> GetAllArticles();
        void DeleteAllArticles();
    }
}

• ligne 6 : pour ajouter un tableau d'articles dans la base

Ultérieurement, pour une autre application, apparaît le besoin de supprimer une liste d'articles enregistrée dans une liste, toujours dans une transaction. On voit que pour répondre à des besoins métier différents, la couche [dao] va être amenée à grossir. On peut prendre une autre voie :

• ne mettre dans la couche [dao] que les opérations basiques InsertArticle, DeleteArticle, UpdateArticle, SelectArticle, SelectArticles
• déporter dans la couche [métier] les opérations de mise à jour simultanée de plusieurs articles. Celles-ci utiliseraient les opérations élémentaires de la couche [dao].

L'avantage de cette solution est que la même couche [dao] pourrait être utilisée sans changement avec différentes couches [metier]. Elle amène une difficulté dans la gestion de la transaction qui regroupe des mises à jour à faire de façon atomique sur la base :

• la transaction doit être initiée par la couche [metier] avant qu'elle n'appelle les méthodes de la couche [dao]
• les méthodes de la couche [dao] doivent connaître l'existence de la transaction afin d'y prendre part si elle existe
• la transaction doit êter terminée par la couche [métier].

Pour que les méthodes de la couche [dao] connaissent l'existence d'une éventuelle transaction en cours, on pourrait ajouter la transaction comme paramètre de chaque méthode de la couche [dao]. Ce paramètre va alors apparaître dans la signature des méthodes de l'interface, ce qui va lier celle-ci à une source de données particulière : la base de données. Les données locales du thread nous apportent une solution plus élégante : la couche [métier] mettra la transaction dans les données locales du thread et c'est là que la couche [dao] ira la chercher. La signature des méthodes de la couche [dao] n'a alors pas besoin d'être changée.

Nous mettons en œuvre cette solution avec le projet Visual studio suivant :

• en [1] : la solution dans son ensemble
• en [2] : les références utilisées. La base [4] étant une base SQL Server Compact, il est nécessaire d'avoir la référence [System.Data.SqlServerCe].
• en [3] : les différentes couches de l'application.

La base [4] est la base SQL Server Compact déjà utilisée dans le chapitre précédent notamment au paragraphe , page .

La classe Article

Une ligne de la table [articles] précédente est encapsulée dans un objet de type Article :

namespace Chap8 {
    public class Article {
        // propriétés
        public int Id { get; set; }
        public string Nom { get; set; }
        public decimal Prix { get; set; }
        public int StockActuel { get; set; }
        public int StockMinimum { get; set; }

        // constructeurs
        public Article() { 
        }

        public Article(int id, string nom, decimal prix, int stockActuel, int stockMinimum) {
            Id = id;
            Nom = nom;
            Prix = prix;
            StockActuel = stockActuel;
            StockMinimum = stockMinimum;
        }

        // identité
        public override string ToString() {
            return string.Format("[{0},{1},{2},{3},{4}]", Id, Nom, Prix, StockActuel, StockMinimum);
        }
    }
}

Interface de la couche [dao]

L'interface IDao de la couche [dao] sera la suivante :

using System.Collections.Generic;

namespace Chap8 {
    public interface IDao {
        int InsertArticle(Article article);
        List<Article> GetAllArticles();
        void DeleteAllArticles();
    }
}

• ligne 5 : pour insérer un article dans la table [articles]
• ligne 6 : pour mettre toutes les lignes de la table [articles] dans une liste d'objets Article
• ligne 7 : pour supprimer toutes les lignes de la table [articles]

Interface de la couche [metier]

L'interface IMetier de la couche [metier] sera la suivante :

using System.Collections.Generic;

namespace Chap8 {
    interface IMetier {
        void InsertArticlesInTransaction(Article[] articles);
        void InsertArticlesOutOfTransaction(Article[] articles);
        List<Article> GetAllArticles();
        void DeleteAllArticles();
    }
}

• ligne 5 : pour insérer, à l'intérieur d'une transaction, un ensemble d'articles
• ligne 6 : idem mais sans transaction
• ligne 7 : pour obtenir la liste de tous les articles
• ligne 8 : pour supprimer tous les articles

Implémentation de la couche [metier]

L'implémentation Metier de l'interface IMetier sera la suivante :

using System.Collections.Generic;
using System.Data;
using System.Data.SqlServerCe;
using System.Threading;

namespace Chap8 {
    public class Metier : IMetier {
        // couche [dao]
        public IDao Dao { get; set; }
        // chaîne de connexion
        public string ConnectionString { get; set; }

        // insertion d'un tableau d'articles à l'intérieur d'une transaction
        public void InsertArticlesInTransaction(Article[] articles) {
            // on crée la connexion à la base
            using (SqlCeConnection connexion = new SqlCeConnection(ConnectionString)) {
                // ouverture connexion
                connexion.Open();
                // transaction
                SqlCeTransaction transaction = null;
                try {
                    // début transaction
                    transaction = connexion.BeginTransaction(IsolationLevel.ReadCommitted);
                    // on enregistre la transaction dans le thread
                    Thread.SetData(Thread.GetNamedDataSlot("transaction"), transaction);
                    // insertion des articles
                    foreach (Article article in articles) {
                        Dao.InsertArticle(article);
                    }
                    // on valide la transaction
                    transaction.Commit();
                } catch {
                    // on défait la transaction
                    if (transaction != null)
                        transaction.Rollback();
                }
            }
        }

        // insertion d'un tableau d'articles sans transaction
        public void InsertArticlesOutOfTransaction(Article[] articles) {
            // insertion des articles
            foreach (Article article in articles) {
                Dao.InsertArticle(article);
            }
        }

        // liste des articles
        public List<Article> GetAllArticles() {
            return Dao.GetAllArticles();
        }
        // supprimer tous les articles
        public void DeleteAllArticles() {
            Dao.DeleteAllArticles();
        }
    }
}

La classe a les propriétés suivantes :

• ligne 9 : une référence sur la couche [dao]
• ligne 11 : la chaîne de connexion qui permet de se connecter à la base de données des articles

Nous ne commentons que la méthode InsertArticlesInTransaction qui seule présente des difficultés :

• ligne 16 : une connexion avec la base est créée
• ligne 18 : elle est ouverte
• ligne 23 : une transaction est créée
• ligne 25 : elle est enregistrée dans les données locales du thread, associée à la clé "transaction"
• lignes 27-29 : la méthode d'insertion unitaire de la couche [dao] est appelée pour chaque article à insérer
• lignes 21 et 32 : l'ensemble de l'insertion du tableau est contrôlée par un try / catch
• ligne 31 : si on arrive là, c'est qu'il n'y a pas eu d'exception. On valide alors la transaction.
• lignes 34-35 : il y a eu exception, on défait la transaction
• ligne 37 : on sort de la clause using. La connexion ouverte en ligne 18 est automatiquement fermée.

Implémentation de la couche [dao]

L'implémentation Dao de l'interface IDao sera la suivante :

using System.Collections.Generic;
using System.Data;
using System.Data.SqlServerCe;
using System.Threading;

namespace Chap8 {
    public class Dao : IDao {
        // chaîne de connexion
        public string ConnectionString { get; set; }
        // requêtes
        public string InsertText { get; set; }
        public string DeleteAllText { get; set; }
        public string GetAllText { get; set; }

        // implémentation interface

        // insertion article
        public int InsertArticle(Article article) {
            // y-a-t-il une transaction en cours ?
            SqlCeTransaction transaction = Thread.GetData(Thread.GetNamedDataSlot("transaction")) as SqlCeTransaction;
            // récupérer la connexion ou la créer
            SqlCeConnection connexion = null;
            if (transaction != null) {
                // récupérer la connexion
                connexion = transaction.Connection as SqlCeConnection;
            } else {
                // la créer
                connexion = new SqlCeConnection(ConnectionString);
                connexion.Open();
            }
            try {
                // préparation commande d'insertion
                SqlCeCommand sqlCommand = new SqlCeCommand();
                sqlCommand.Transaction = transaction;
                sqlCommand.Connection = connexion;
                sqlCommand.CommandText = InsertText;
                sqlCommand.Parameters.Add("@nom", SqlDbType.NVarChar, 30);
                sqlCommand.Parameters.Add("@prix", SqlDbType.Money);
                sqlCommand.Parameters.Add("@sa", SqlDbType.Int);
                sqlCommand.Parameters.Add("@sm", SqlDbType.Int);
                sqlCommand.Parameters["@nom"].Value = article.Nom;
                sqlCommand.Parameters["@prix"].Value = article.Prix;
                sqlCommand.Parameters["@sa"].Value = article.StockActuel;
                sqlCommand.Parameters["@sm"].Value = article.StockMinimum;
                // exécution
                return sqlCommand.ExecuteNonQuery();
            } finally {
                // si on n'était pas dans une transaction, on ferme la connexion
                if (transaction == null) {
                    connexion.Close();
                }
            }
        }

        // liste des articles
        public List<Article> GetAllArticles() {
...
        }

        // suppression des articles
        public void DeleteAllArticles() {
...
        }
    }
}

La classe a les propriétés suivantes :

• ligne 9 : la chaîne de connexion qui permet de se connecter à la base de données des articles
• ligne 11 : l'ordre SQL pour insérer un article
• ligne 12 : l'ordre SQL pour suprrimer tous les articles
• ligne 13 : l'ordre SQL pour obtenir tous les articles

Ces propriétés seront initialisées à partir du fichier de configuration [App.config] suivant :

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <connectionStrings>
        <add name="dbArticlesSqlServerCe" connectionString="Data Source=|DataDirectory|\dbarticles.sdf;Password=dbarticles;" />
    </connectionStrings>
    <appSettings>
        <add key="insertText" value="insert into articles(nom,prix,stockactuel,stockminimum) values(@nom,@prix,@sa,@sm)"/>
        <add key="getAllText" value="select id,nom,prix,stockactuel,stockminimum from articles"/>
        <add key="deleteAllText" value="delete from articles"/>
    </appSettings>
</configuration>

Nous commentons la méthode InsertArticle :

• ligne 20 : on récupère l'éventuelle transaction qu'a pu placer la couche [metier] dans le thread
• lignes 23-25 : si la transaction est présente, on récupère la connexion à laquelle elle a été liée.
• lignes 26-30 : sinon, une connexion nouvelle est créée et ouverte.
• lignes 33-44 : on prépare la commande d'insertion. Celle-ci est paramétrée (cf ligne g de App.config).
• ligne 33 : l'objet Command est créé.
• ligne 34 : il est associé à la transaction courante. Si celle-ci n'existe pas (transaction=null), cela revient à exécuter l'ordre SQL sans transaction explicite. On rappelle qu'alors il y a quand même une transaction implicite. Avec SQL Server CE, cette transaction implicite est par défaut en mode autocommit : l'ordre SQL est committé après son exécution.
• ligne 35 : l'objet Command est associé à la connexion courante
• ligne 36 : le texte SQl à exécuter est fixé. C'est la requête paramétrée de la ligne g de App.config.
• lignes 37-44 : les 4 paramètres de la requête sont initialisés
• ligne 46 : la requête est exécutée.
• lignes 49-51 : il faut se souvenir que s'il n'y avait pas de transaction, une nouvelle connexion a été ouverte avec la base, lignes 26-30. Dans ce cas, elle doit être fermée. S'il y avait une transaction, la connexion ne doit pas être fermée car c'est la couche [metier] qui la gère.

Les deux autres méthodes reprennent ce qui a été vu dans le chapitre "Bases de données" :

        // liste des articles
        public List<Article> GetAllArticles() {
            // liste des articles - vide au départ
            List<Article> articles = new List<Article>();
            // exploitation connexion
            using (SqlCeConnection connexion = new SqlCeConnection(ConnectionString)) {
                // ouverture connexion
                connexion.Open();
                // exécute sqlCommand avec requête select
                SqlCeCommand sqlCommand = new SqlCeCommand(GetAllText, connexion);
                using (SqlCeDataReader reader = sqlCommand.ExecuteReader()) {
                    // exploitation résultat
                    while (reader.Read()) {
                        // exploitation ligne courante
                        articles.Add(new Article(reader.GetInt32(0), reader.GetString(1), reader.GetDecimal(2), reader.GetInt32(3), reader.GetInt32(4)));
                    }
                }
            }
            // on rend le résultat
            return articles;
        }

        // suppression des articles
        public void DeleteAllArticles() {
            using (SqlCeConnection connexion = new SqlCeConnection(ConnectionString)) {
                // ouverture connexion
                connexion.Open();
                // exécute sqlCommand avec requête de mise à jour
                new SqlCeCommand(DeleteAllText, connexion).ExecuteNonQuery();
            }
}

L'application [console] de test

L'application [console] de test est la suivante :

using System;
using System.Configuration;

namespace Chap8 {
    class Program {
        static void Main(string[] args) {
            // exploitation du fichier de configuration
            string connectionString = null;
            string insertText;
            string getAllText;
            string deleteAllText;
            try {
                // chaîne de connexion
                connectionString = ConfigurationManager.ConnectionStrings["dbArticlesSqlServerCe"].ConnectionString;
                // autres paramètres
                insertText = ConfigurationManager.AppSettings["insertText"];
                getAllText = ConfigurationManager.AppSettings["getAllText"];
                deleteAllText = ConfigurationManager.AppSettings["deleteAllText"];
            } catch (Exception e) {
                Console.WriteLine("Erreur de configuration : {0}", e.Message);
                return;
            }
            // création couche [dao]
            Dao dao = new Dao();
            dao.ConnectionString = connectionString;
            dao.DeleteAllText = deleteAllText;
            dao.GetAllText = getAllText;
            dao.InsertText = insertText;
            // création couche [métier]
            Metier metier = new Metier();
            metier.Dao = dao;
            metier.ConnectionString = connectionString;
            // on crée un tableau d'articles
            Article[] articles = new Article[2];
            for (int i = 0; i < articles.Length; i++) {
                articles[i] = new Article(0, "article", 100, 10, 1);
            }
            // on supprime tous les articles
            Console.WriteLine("Suppression de tous les articles...");
            metier.DeleteAllArticles();
            // on insère le tableau hors transaction
            Console.WriteLine("Insertion des articles hors transaction...");
            try {
                metier.InsertArticlesOutOfTransaction(articles);
            } catch (Exception e){
                Console.WriteLine("Exception : {0}", e.Message);
            }
            // on affiche les articles
            Console.WriteLine("Liste des articles");
            AfficheArticles(metier);
            // on supprime tous les articles
            Console.WriteLine("Suppression de tous les articles...");
            metier.DeleteAllArticles();
            // on insère le tableau dans une transaction
            Console.WriteLine("Insertion des articles dans une transaction...");
            metier.InsertArticlesInTransaction(articles);
            // on affiche les articles
            Console.WriteLine("Liste des articles");
            AfficheArticles(metier);
        }

        private static void AfficheArticles(IMetier metier) {
            // on affiche les articles
            foreach(Article article in metier.GetAllArticles()){
                Console.WriteLine(article);
            }
        }

    }
}

• lignes 12-22 : le fichier [App.config] est exploité.
• lignes 24-28 : la couche [dao] est instanciée et initialisée
• lignes 30-32 : il est fait de même pour la couche [metier]
• lignes 34-37 : on crée un tableau de 2 articles avec le même nom. La table [articles] de la base SQL server Ce [dbarticles.sdf] a une contrainte d'unicité sur le nom. L'insertion du 2ième article sera donc refusée. Si l'insertion du tableau se fait hors transaction, le 1er article sera d'abord inséré puis le restera. Si l'insertion du tableau se fait dans une transaction, le 1er article sera d'abord inséré puis sera retiré, lors du Rollback de la transaction.
• lignes 39-50 : insertion hors transaction du tableau de 2 articles et vérification.
• lignes 52-59 : idem mais dans une transaction

Les résultats à l'exécution sont les suivants :

Suppression de tous les articles...
Insertion des articles hors transaction...
Exception : A duplicate value cannot be inserted into a unique index. [ Table na
me = ARTICLES,Constraint name = UQ__ARTICLES__0000000000000010 ]
Liste des articles
[7,article,100,10,1]
Suppression de tous les articles...
Insertion des articles dans une transaction...
Liste des articles

• lignes 5-6 : l'insertion hors transaction a laissé le 1er article dans la base
• ligne 9 : l'insertion faite dans une transaction n'a laissé aucun article dans la base

L'exemple précédent a montré l'intérêt des données locales à un thread pour la gestion des transactions. Il n'est pas à reproduire tel quel. Des frameworks tels que Spring, Nhibernate… utilisent cette technique mais la rendent encore plus transparente : il est possible pour la couche [metier] d'utiliser des transactions sans que la couche [dao] n'ait besoin de le savoir. Il n'y a alors aucun objet Transaction dans le code de la couche [dao]. Cela est obtenu au moyen d'une technique de proxy appelée AOP (Aspects Oriented Programming). De nouveau on ne peut qu'inciter le lecteur à utiliser ces frameworks.