Java et la synchronisation

Tout d'abord, voyons un problème de synchronisation classique. Plusieurs entités récepteurs (threads) reçoivent une demande d'un client. Ils peuvent déposer des travaux dans une file. Les ouvriers prennent les travaux déposés, les traitent, et fournissent un résultat dans une autre file. L'émetteur récupère ces résultats et peut les envoyer au client.

Plusieurs problèmes de synchronisation se posent ici :

1. Plusieurs récepteurs ne peuvent pas déposer simultanément un travail dans la file des travaux, sinon les travaux seraient sur la même case ;
2. Si la file des travaux est pleine, les récepteurs doivent attendre qu'une case se libère pour déposer un nouveau travail ;
3. Plusieurs ouvriers ne peuvent pas prendre chacun un travail simultanément, sinon ils auraient le même travail à traiter ;
4. Si la file des travaux est vide, les ouvriers doivent attendre qu'un travail soit déposé pour pouvoir le traiter ;
5. Plusieurs ouvriers ne peuvent pas déposer simultanément le résultat d'un travail dans la file des résultats, sinon les résultats seraient sur la même case ;
6. Si la file des résultats est pleine, les ouvriers doivent attendre qu'une case se libère pour déposer un nouveau résultat ;
7. Si la file des résultats est vide, l'émetteur doit attendre qu'un résultat soit disponible.

Le but est de résoudre ces problèmes généraux, auxquels on peut dans la majorité des cas se ramener.

Pour les résoudre correctement, il faut assurer :

• la sûreté : rien de mauvais ne se produit, quel que soit l'entrelacement des threads (deux ouvriers ne peuvent jamais prendre le même travail) ;
• la vivacité : quelque chose de bon finit par se produire (si la file des travaux n'est pas vide, un ouvrier finira par prendre les travaux).

Il faut aussi prendre en compte les cas possibles ; par exemple, deux travaux déposés consécutivement peuvent être exécutés séquentiellement par le même ouvrier.

Pour réaliser ceci en Java, la méthode la plus simple est d'utiliser le mot-clé synchronized.

Voici comment il s'utilise :

synchronized(unObjet) {
    //section critique
}

unObjet représente un verrou, qui peut être un objet Java quelconque. Attention cependant, il vaut mieux utiliser des références déclarées final, pour être sûr que la référence vers l'objet n'est pas modifiée ; en effet, le cas de figure ci-dessous ne fonctionne pas, car lorsque plusieurs threads arrivent au bloc synchronisé, la variable maListe ne référence pas toujours le même objet, et donc ne représente pas toujours le même verrou.

synchronized(maListe) {
    maListe = new ArrayList<String>();
}

Cas particulier : lorsque l'objet qui sert de verrou pour la synchronisation est this, et qu'il englobe tout le code d'une méthode, on peut mettre le mot-clé synchronized dans la signature de la méthode. Les deux codes ci-dessous sont strictement équivalents :

void methode() {
    synchronized(this) {
        //section critique
    }
}

synchronized void methode() {
    //section critique
}

Une autre méthode pour réaliser des verrous est apparue dans Java 1.5. À première vue, elle peut paraître plus compliquée, mais elle est aussi plus puissante, dans le sens où elle permet de faire des choses que le mot-clé synchronized ne permet pas (nous y reviendrons plus tard).

Voici comment l'utiliser :

Lock l = new ReentrantLock();
l.lock();
try {
    //section critique
} finally {
    l.unlock();
}

Pour comparer cette méthode avec la précédente, l.lock() et l.unlock() correspondent respectivement au début et à la fin du bloc synchronized.

Cependant, si vous désirez faire une exclusion mutuelle aussi simple que celles des exemples présentés ici, je vous conseille d'utiliser synchronized, et de réserver cette méthode pour des cas bien particuliers, que nous verrons ultérieurement.

III-A-1. Utilisation▲

class ListeTab {
 
    private String[] tab = new String[50];
    private int index = 0;
 
    synchronized void ajoute(String s) {
        tab[index] = s;
        index++;
        notify();
        System.out.println("notify() exécuté"); 
    }
 
    synchronized String getPremierElementBloquant() {
        //tant que la liste est vide
        while(index == 0) {
            try {
                //attente passive
                wait();
            } catch(InterruptedException ie) {
                ie.printStackTrace();
            }
        }
        return tab[0];
    }
 
}

III-A-2. Limites▲

class UneClasse {
 
    private final Object lock1 = new Object();
    private final Object lock2 = new Object();
 
    void methode() {
        synchronized(lock1) {
            synchronized(lock2) {
                while(condition) {
                    lock2.wait();
                }
            }
        }
    }
 
    void notifie() {
        lock2.notify();
    }
 
}

La solution que nous avons vue pour réaliser l'exclusion mutuelle utilisant ce package permet aussi d'aller au-delà des limites des méthodes de la classe Object. Le principe est de n'utiliser qu'un seul verrou, mais avec plusieurs variables condition (sur lesquelles nous pourrons effectuer les opérations similaires à wait() et à notify()).

class UneClasse {
 
    private final Lock lock = new ReentrantLock();
    private final Condition cond1 = lock.newCondition();
    private final Condition cond2 = lock.newCondition();
 
    void methode1() throws InterruptedException {
        lock.lock();
        try {
            cond1.await();
            cond2.signal();
        } finally {
            lock.unlock();
        }
    }
 
    void methode2() throws InterruptedException {
        lock.lock();
        try {
            cond1.signal();
            cond2.await();
        } finally {
            lock.unlock();
        }
    }
 
}

Maintenant, les appels à cond1.await() et cond2.await() libèrent bien le verrou lock.

Une interface ReadWriteLock est aussi disponible dans ce package, permettant de résoudre les problèmes de lecture-écriture (à tout moment, soit un nombre quelconque de lecteurs, soit un et un seul écrivain). Je vous laisse consulter la documentation pour son utilisation, mais il est bon de savoir que cela existe.

Jusqu'ici, le mot thread désignait un processus léger. Dans cette section, le mot Thread signifiera la classe Thread de Java. La relation existant entre les deux est que l'appel à la méthode start() de la classe Thread crée un nouveau thread dans lequel du code est exécuté.

Ceci n'est pas un article sur la classe Thread, mais voici quelques méthodes à connaître :

• static Thread currentThread() : permet d'obtenir le thread courant ;
• static void yield() : laisse une chance aux autres threads de s'exécuter ;
• static void sleep(long ms) throws InterruptedException : suspend l'exécution du thread appelant pendant la durée indiquée (ne pas utiliser ceci à des fins de synchronisation !) ;
• void interrupt() : provoque soit la levée de l'exception InterruptedException si l'activité est bloquée sur une opération de synchronisation, soit le positionnement d'un indicateur interrupted ;
• void join() : attente bloquante de la terminaison de l'exécution du thread (jusqu'à ce que la méthode run() associée au Thread ait fini de s'exécuter).

Impossible d'écrire un tutoriel concernant la synchronisation sans parler des sémaphores. Dans une présentation plus théorique des problèmes de synchronisation, les sémaphores seraient présentés avant les deux solutions précédentes ; mais, en pratique, vous n'aurez probablement pas besoin de les utiliser en Java. Cependant, je trouve que la compréhension de leur fonctionnement est importante.

La classe Semaphore est apparue dans Java 1.5.

III-D-1. Définition▲

III-D-2. Utilisation▲

Semaphore sem = new Semaphore(1);
    try {
        sem.acquire();
        //section critique
        sem.release();
    } catch(InterruptedException e) {
        e.printStackTrace();
    }