Thinking in Java, 3rd ed. Revision 4.0

Quand on sait qu'on a déjà fait ce qu'on voulait dans la méthode run( ), on peut suggérer au mécanisme d'ordonnancement des threads qu'on en a fait assez et qu'un autre thread peut disposer de l'UCT. Cette suggestion (et ce n'est qu'une suggestion - rien ne garantit que l'implémentation en tiendra compte) prend la forme de la méthode yield( ).

On peut modifier l'exemple précédent en cédant la main après chaque boucle :

//: c13:YieldingThread.java
// On suggère quand commuter les threads avec la méthode yield().
import com.bruceeckel.simpletest.*;

public class YieldingThread extends Thread {
    private static Test monitor = new Test();
    private int countDown = 5;
    private static int threadCount = 0;
    public YieldingThread() {
        super("" + ++threadCount);
        start();
    }
    public String toString() {
        return "#" + getName() + ": " + countDown;
    }
    public void run() {
        while(true) {
            System.out.println(this);
            if(--countDown == 0) return;
            yield();
        }
    }
    public static void main(String[] args) {
        for(int i = 0; i < 5; i++)
            new YieldingThread();
        monitor.expect(new String[] {
            "#1: 5",
            "#2: 5",
            "#4: 5",
            "#5: 5",
            "#3: 5",
            "#1: 4",
            "#2: 4",
            "#4: 4",
            "#5: 4",
            "#3: 4",
            "#1: 3",
            "#2: 3",
            "#4: 3",
            "#5: 3",
            "#3: 3",
            "#1: 2",
            "#2: 2",
            "#4: 2",
            "#5: 2",
            "#3: 2",
            "#1: 1",
            "#2: 1",
            "#4: 1",
            "#5: 1",
            "#3: 1"
        }, Test.IGNORE_ORDER + Test.WAIT);
    }
} ///:~

La méthode yield( ) permet de répartir beaucoup mieux les résultats. Mais on notera que si la chaîne de caractères résultante est plus longue, le résultat sera à peu près le même qu'avec SimpleThread.java (on essaiera en changeant la méthode toString( ) de sorte qu'elle produise des chaînes de caractères de plus en plus longues et l'on observera ce qui se passe). Comme le mécanisme d'ordonnancement est préemptif, il décide d'interrompre un thread et de commuter vers un autre quand il le veut ; par conséquent, si l'E/S (qui est exécutée par le thread main( ) ) prend trop de temps, elle sera interrompue avant que run( ) puisse exécuter yield( ). En général, la méthode yield( ) n'est utile que dans de rares occasions, et l'on ne peut s'y fier pour effectuer une mise au point sérieuse d'une application.

L'appel à la méthode sleep( ) est un autre moyen de contrôler le comportement des threads en cessant leur exécution pendant un nombre donné de millisecondes. Dans l'exemple précédent, si l'on remplace l'appel à yield( ) par un appel à sleep( ), on obtient le programme suivant :

//: c13:SleepingThread.java
// Appel à sleep() pour cesser l'exécution pendant un certain temps.
import com.bruceeckel.simpletest.*;

public class SleepingThread extends Thread {
    private static Test monitor = new Test();
    private int countDown = 5;
    private static int threadCount = 0;
    public SleepingThread() {
        super("" + ++threadCount);
        start();
    }
    public String toString() {
        return "#" + getName() + ": " + countDown;
    }
    public void run() {
        while(true) {
            System.out.println(this);
            if(--countDown == 0) return;
            try {
                sleep(100);
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
        }
    }
    public static void
    main(String[] args) throws InterruptedException {
        for(int i = 0; i < 5; i++)
            new SleepingThread().join();
        monitor.expect(new String[] {
            "#1: 5",
            "#1: 4",
            "#1: 3",
            "#1: 2",
            "#1: 1",
            "#2: 5",
            "#2: 4",
            "#2: 3",
            "#2: 2",
            "#2: 1",
            "#3: 5",
            "#3: 4",
            "#3: 3",
            "#3: 2",
            "#3: 1",
            "#4: 5",
            "#4: 4",
            "#4: 3",
            "#4: 2",
            "#4: 1",
            "#5: 5",
            "#5: 4",
            "#5: 3",
            "#5: 2",
            "#5: 1"
        });
    }
} ///:~

L'appel à sleep( ) doit être placé dans un bloc try car sleep( ) peut être interrompu avant que la pause ne prenne fin. Cela arrive lorsqu'un élément possède une référence au thread et lui applique la méthode interrupt( ) (interrupt( ) a aussi un effet sur le thread si les méthodes wait( ) ou join( ) lui ont été appliquées ; les appels à ces méthodes doivent donc être placés dans un bloc try similaire - on étudiera ces méthodes plus tard). D'ordinaire, lorsqu'on se propose de sortir d'un thread suspendu via interrupt( ), on utilise la méthode wait( ) plutôt que la méthode sleep( ), de façon à ce qu'il soit peu probable que la sortie se produise à l'intérieur de la clause catch. On suit ici le précepte « Ne récupérez pas une exception, à moins que vous ne sachiez quoi faire avec », en la jetant à nouveau en tant que RuntimeException.

On notera que le résultat est déterministe - chaque thread effectue son décrément avant que le suivant démarre. Cela est dû au fait que join( ) (qu'on étudiera bientôt) est appliqué à chaque thread, de sorte que la méthode main( ) attend que le thread ait fini avant de continuer. Si l'on n'utilisait pas join( ), on verrait que les threads ont tendance à s'exécuter dans n'importe quel ordre, ce qui signifie que la méthode sleep( ) n'est pas non plus un moyen de contrôler l'ordre d'exécution des threads. Elle ne fait que suspendre momentanément l'exécution d'un thread. La seule garantie qu'elle procure est que le thread s'endormira pendant au moins 100 millisecondes ; mais le thread peut reprendre son exécution après un laps de temps plus long, parce que l'ordonnanceur de thread doit le recontacter après que le délai de sommeil a expiré.

Si l'on doit contrôler l'ordre d'exécution des threads, le mieux est de ne pas utiliser de thread du tout, mais au contraire d'écrire ses propres routines de coopération qui donnent le contrôle à chacun d'entre eux dans un ordre donné.

La priorité d'un thread indique à l'ordonnanceur l'importance de ce thread. Bien que l'ordre que l'UCT affecte à un jeu de threads existants soit indéterminé, l'ordonnanceur tendra à servir d'abord le thread de plus grande priorité, lorsque de nombreux threads sont bloqués en attente d'exécution. Néanmoins, cela ne signifie pas que les threads de moindre priorité ne seront pas exécutés (c'est-à-dire que les priorités ne génèrent pas d'interblocage). Les threads de moindre priorité ont simplement tendance à être exécutés moins souvent.

Voici le programme SimpleThread.java modifié pour montrer le fonctionnement des niveaux de priorités. Les priorités sont réglées par la méthode setPriority( ) de la classe Thread.

//: c13:SimplePriorities.java
// Montre l'utilisation des priorités des threads.
import com.bruceeckel.simpletest.*;

public class SimplePriorities extends Thread {
    private static Test monitor = new Test();
    private int countDown = 5;
    private volatile double d = 0; // Pas d'optimisation
    public SimplePriorities(int priority) {
        setPriority(priority);
        start();
    }
    public String toString() {
        return super.toString() + ": " + countDown;
    }
    public void run() {
        while(true) {
            // Une opération coûteuse et interruptible :
            for(int i = 1; i < 100000; i++)
                d = d + (Math.PI + Math.E) / (double)i;
            System.out.println(this);
            if(--countDown == 0) return;
        }
    }
    public static void main(String[] args) {
        new SimplePriorities(Thread.MAX_PRIORITY);
        for(int i = 0; i < 5; i++)
            new SimplePriorities(Thread.MIN_PRIORITY);
        monitor.expect(new String[] {
            "Thread[Thread-1,10,main]: 5",
            "Thread[Thread-1,10,main]: 4",
            "Thread[Thread-1,10,main]: 3",
            "Thread[Thread-1,10,main]: 2",
            "Thread[Thread-1,10,main]: 1",
            "Thread[Thread-2,1,main]: 5",
            "Thread[Thread-2,1,main]: 4",
            "Thread[Thread-2,1,main]: 3",
            "Thread[Thread-2,1,main]: 2",
            "Thread[Thread-2,1,main]: 1",
            "Thread[Thread-3,1,main]: 5",
            "Thread[Thread-4,1,main]: 5",
            "Thread[Thread-5,1,main]: 5",
            "Thread[Thread-6,1,main]: 5",
            "Thread[Thread-3,1,main]: 4",
            "Thread[Thread-4,1,main]: 4",
            "Thread[Thread-5,1,main]: 4",
            "Thread[Thread-6,1,main]: 4",
            "Thread[Thread-3,1,main]: 3",
            "Thread[Thread-4,1,main]: 3",
            "Thread[Thread-5,1,main]: 3",
            "Thread[Thread-6,1,main]: 3",
            "Thread[Thread-3,1,main]: 2",
            "Thread[Thread-4,1,main]: 2",
            "Thread[Thread-5,1,main]: 2",
            "Thread[Thread-6,1,main]: 2",
            "Thread[Thread-4,1,main]: 1",
            "Thread[Thread-3,1,main]: 1",
            "Thread[Thread-6,1,main]: 1",
            "Thread[Thread-5,1,main]: 1"
        }, Test.IGNORE_ORDER + Test.WAIT);
    }
} ///:~

Dans cette version, la méthode toString( ) est redéfinie pour utiliser Thread.toString( ), qui imprime le nom du thread , son niveau de priorité et le « groupe de thread » auquel il appartient. On définit soi-même le nom du thread via le constructeur ; ici, il est automatiquement généré sous la forme Thread-1, Thread-2, etc. Comme les threads s'identifient eux-mêmes, il n'y a pas de numéroDeThread dans cet exemple. La méthode toString( ) redéfinie indique aussi la valeur du compteur du thread.

On voit que le niveau de priorité du thread 1 est maximal, tous les autres threads ont un niveau de priorité minimal.

On a ajouté à l'intérieur de la méthode run( ) une boucle de 100 000 passes comprenant un calcul en virgule flottante plutôt gourmand et qui implique une addition et une division sur des double. On a rendu la variable d volatile pour s'assurer qu'aucune optimisation n'aurait lieu. Sans ce calcul, on ne verrait pas l'influence de la fixation des niveaux de priorité (on essaiera en mettant en commentaires la boucle for contenant les calculs en double). Avec ce calcul, on voit que l'ordonnanceur donne la préférence au thread 1 (en tout cas, c'est ce qui se passe sur ma machine Windows 2000). Même si l'impression sur la console est aussi une opération coûteuse, on ne voit pas les niveaux de priorité de cette façon, parce que l'impression sur la console n'est pas interrompue (autrement, l'affichage sur la console deviendrait incompréhensible pendant les opérations sur thread), tandis que le calcul mathématique peut être interrompu. Le calcul dure suffisamment longtemps pour que le mécanisme d'ordonnancement des threads intervienne, modifie les threads et tienne compte des priorités, de sorte que le thread 1 ait la préférence.

On peut aussi lire la priorité d'un thread existant avec la méthode getPriority( ) et la changer à tout moment (et pas seulement dans le constructeur comme cela a été fait dans SimplePriorities.java) avec setPriority( ).

Bien que le JDK possède 10 niveaux de priorité, cela ne correspond pas bien au niveau de priorité de nombreux systèmes opératoires. Par exemple, Windows 2000 possède 7 niveaux de priorité, qui ne sont pas fixés, par conséquent la correspondance est indéterminée (bien que Solaris de Sun ait 2³¹ niveaux). La seule approche portable est de s'en tenir à MAX_PRIORITY, NORM_PRIORITY et MIN_PRIORITY lorsque l'on règle les niveaux de priorité.

Un thread « démon » est un thread fait pour fournir un service général en arrière-plan aussi longtemps que le programme tourne, mais il ne constitue pas une partie essentielle du programme. Par conséquent, quand tous les threads non-démons se terminent, le programme s'arrête. À l'inverse, s'il y a au moins un thread non-démon en cours d'exécution, le programme ne s'arrête pas. Par exemple, il existe un thread non-démon qui exécute la méthode main( ).

//: c13:SimpleDaemons.java
// Les threads démons n'empêchent pas le programme de se terminer.

public class SimpleDaemons extends Thread {
    public SimpleDaemons() {
        setDaemon(true); // Doit être appelé avant start()
        start();
    }
    public void run() {
        while(true) {
            try {
                sleep(100);
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
            System.out.println(this);
        }
    }
    public static void main(String[] args) {
        for(int i = 0; i < 10; i++)
            new SimpleDaemons();
    }
} ///:~

On doit spécifier que le thread est un thread démon en appelant la méthode setDaemon( ) avant que le thread soit démarré. À l'intérieur de la méthode run( ), le thread est mis en sommeil pendant un court instant. Lorsque tous les threads ont été démarrés, le programme se termine immédiatement, avant qu'aucun n'ait pu imprimer ses propres données, car il n'existe pas de thread non-démon (autre que main( )) qui maintienne le programme en fonctionnement. Il se termine donc sans qu'aucune impression n'ait eu lieu.

On peut détecter si un thread est un démon via la méthode isDaemon( ). Si un thread est un thread démon, alors tout thread créé par lui devient automatiquement un démon, comme l'exemple suivant le prouve :

//: c13:Daemons.java
// Les threads démons engendrent d'autres threads démons.
import java.io.*;
import com.bruceeckel.simpletest.*;

class Daemon extends Thread {
    private Thread[] t = new Thread[10];
    public Daemon() {
        setDaemon(true);
        start();
    }
    public void run() {
        for(int i = 0; i < t.length; i++)
            t[i] = new DaemonSpawn(i);
        for(int i = 0; i < t.length; i++)
            System.out.println("t[" + i + "].isDaemon() = "
                + t[i].isDaemon());
        while(true)
            yield();
    }
}

class DaemonSpawn extends Thread {
    public DaemonSpawn(int i) {
        start();
        System.out.println("DaemonSpawn " + i + " started");
    }
    public void run() {
        while(true)
            yield();
    }
}

public class Daemons {
    private static Test monitor = new Test();
    public static void main(String[] args) throws Exception {
        Thread d = new Daemon();
        System.out.println("d.isDaemon() = " + d.isDaemon());
        // Permet aux threads démons de 
        // terminer leur processus de démarrage :
        Thread.sleep(1000);
        monitor.expect(new String[] {
            "d.isDaemon() = true",
            "DaemonSpawn 0 started",
            "DaemonSpawn 1 started",
            "DaemonSpawn 2 started",
            "DaemonSpawn 3 started",
            "DaemonSpawn 4 started",
            "DaemonSpawn 5 started",
            "DaemonSpawn 6 started",
            "DaemonSpawn 7 started",
            "DaemonSpawn 8 started",
            "DaemonSpawn 9 started",
            "t[0].isDaemon() = true",
            "t[1].isDaemon() = true",
            "t[2].isDaemon() = true",
            "t[3].isDaemon() = true",
            "t[4].isDaemon() = true",
            "t[5].isDaemon() = true",
            "t[6].isDaemon() = true",
            "t[7].isDaemon() = true",
            "t[8].isDaemon() = true",
            "t[9].isDaemon() = true"
        }, Test.IGNORE_ORDER + Test.WAIT);
    }
} ///:~

Le thread Daemon positionne son drapeau démon à « vrai », puis génère une poignée d'autres threads - qui ne se mettent pas eux-mêmes en mode démon - pour montrer qu'ils deviennent quand même des démons. Ensuite il entre dans une boucle infinie qui appelle yield( ) pour redonner le contrôle aux autres processus.

Rien n'empêche le programme de se terminer une fois que la méthode main( ) a fini son travail, puisqu'il n'y a que des threads démons qui s'exécutent. Le thread main( ) est mis en sommeil pendant une seconde pour que l'on puisse voir les effets du démarrage de tous les threads démons. Sans cela, on ne verrait que quelques-uns des effets résultant de leur création (on fera varier le délai de sleep( ) pour observer ce comportement).

Un thread peut appeler la méthode join( ) sur un autre thread, de façon à ce qu'il démarre après que le second thread s'est achevé. Si un thread appelle t.join( ) sur un autre thread t, alors le thread appelant est suspendu jusqu'à ce que le thread cible t se termine (lorsque t.isAlive( ) devient faux).

On peut aussi fournir à la méthode join( ) un paramètre de temps (en millisecondes ou en nanosecondes), de sorte que si le thread cible ne s'achève pas dans ce laps de temps, l'appel à la méthode join( ) retourne quand même au processus appelant.

On peut interrompre l'appel à la méthode join( ) via un appel à la méthode interrupt( ) sur le thread appelant ; une structure try-catch est donc obligatoire.

L'exemple suivant illustre toutes ces opérations :

//: c13:Joining.java
// Comprendre la méthode join().
import com.bruceeckel.simpletest.*;

class Sleeper extends Thread {
    private int duration;
    public Sleeper(String name, int sleepTime) {
        super(name);
        duration = sleepTime;
        start();
    }
    public void run() {
        try {
            sleep(duration);
        } catch (InterruptedException e) {
            System.out.println(getName() + " was interrupted. " +
                "isInterrupted(): " + isInterrupted());
            return;
        }
        System.out.println(getName() + " has awakened");
    }
}

class Joiner extends Thread {
    private Sleeper sleeper;
    public Joiner(String name, Sleeper sleeper) {
        super(name);
        this.sleeper = sleeper;
        start();
    }
    public void run() {
        try {
            sleeper.join();
        } catch (InterruptedException e) {
            throw new RuntimeException(e);
        }
        System.out.println(getName() + " join completed");
    }
}

public class Joining {
    private static Test monitor = new Test();
    public static void main(String[] args) {
        Sleeper
            sleepy = new Sleeper("Sleepy", 1500),
            grumpy = new Sleeper("Grumpy", 1500);
        Joiner
            dopey = new Joiner("Dopey", sleepy),
            doc = new Joiner("Doc", grumpy);
        grumpy.interrupt();
        monitor.expect(new String[] {
            "Grumpy was interrupted. isInterrupted(): false",
            "Doc join completed",
            "Sleepy has awakened",
            "Dopey join completed"
        }, Test.AT_LEAST + Test.WAIT);
    }
} ///:~

Un Sleeper est un type de Thread qui s'endort pendant un laps de temps spécifié dans son constructeur. À l'intérieur de la méthode run( ), l'appel à sleep( ) peut se terminer lorsque le laps de temps est écoulé, mais il peut aussi être interrompu. Dans la structure catch, on rend compte de l'interruption ainsi que de la valeur de la méthode isInterrupted( ). Quand un autre thread appelle interrupt( ) sur ce thread, un drapeau est positionné pour indiquer que le thread a été interrompu. Néanmoins, ce drapeau est effacé quand l'exception est capturée ; le résultat est donc toujours faux à l'intérieur de la structure catch. Ce drapeau est utilisé dans le cas où un thread voudrait examiner son état d'interruption en dehors de l'exception.

Un Joiner est un thread qui attend qu'un Sleeper se réveille en appelant la méthode join( ) sur l'objet Sleeper. Dans la méthode main( ), chaque Sleeper est couplé à un Joiner, et l'on voit dans le résultat que si le Sleeper est interrompu ou qu'il s'achève normalement, le Joiner s'achève conjointement avec le Sleeper.

Dans les exemples simples que l'on a vus jusqu'à présent, les objets threads héritent tous de la classe Thread. C'est logique puisque tous les objets ne sont manifestement créés que comme threads et n'ont pas d'autres fonctions. Néanmoins, il se peut que la classe hérite déjà d'une autre classe, auquel cas on ne peut la faire hériter de la classe Thread (Java ne gère pas l'héritage multiple). En l'occurrence, on peut utiliser l'approche alternative qui consiste à implémenter l'interface Runnable. Runnable précise seulement qu'il faut implémenter la méthode run( ), et la classe Thread implémente, elle aussi, Runnable.

Cet exemple montre l'essentiel :

//: c13:RunnableThread.java
// SimpleThread utilisant l'interface Runnable.

public class RunnableThread implements Runnable {
    private int countDown = 5;
    public String toString() {
        return "#" + Thread.currentThread().getName() +
            ": " + countDown;
    }
    public void run() {
        while(true) {
            System.out.println(this);
            if(--countDown == 0) return;
        }
    }
    public static void main(String[] args) {
        for(int i = 1; i <= 5; i++)
            new Thread(new RunnableThread(), "" + i).start();
        // Résultat identique à celui de SimpleThread.java
    }
} ///:~

La seule chose requise par une classe Runnable est une méthode run( ), mais si l'on veut faire autre chose avec l'objet Thread (comme getName( ) dans la méthode toString( )) on doit obtenir une référence à cet objet en appelant Thread.currentThread( ). Ce constructeur Thread spécial accepte en paramètres un Runnable et un nom pour le thread.

Le fait pour un élément de posséder une interface Runnable signifie simplement qu'il possède une méthode run( ), rien de plus - cela n'engendre aucune aptitude innée au mécanisme de thread, comme celles d'une classe héritée de la classe Thread. Ainsi, pour générer un thread à partir d'un objet Runnable, on doit créer un objet Thread distinct - comme indiqué dans cet exemple - en passant l'objet Runnable au constructeur Thread spécial. On peut alors appliquer à ce thread la méthode start( ), qui effectue l'initialisation courante et appelle ensuite la méthode run( ).

Ce qu'il y a de commode avec l'interface Runnable, c'est que tout appartient à la même classe ; c'est-à-dire que Runnable permet une sous-classe abstraite en association avec une classe de base et d'autres interfaces. Si l'on a besoin d'accéder à un élément, on le fait simplement sans passer par un objet distinct. Néanmoins, les classes internes fournissent ce même accès simple à toutes les parties d'une classe externe ; l'accès aux membres d'une classe n'est donc pas une raison impérative d'utiliser Runnable comme une sous-classe abstraite plutôt que d'utiliser une sous-classe interne à la classe Thread.

L'utilisation de Runnable indique, en général, que l'on veut créer un processus dans une partie de code - implémenté dans la méthode run( ) - plutôt que de créer un objet représentant ce processus. On peut débattre de la question, selon que l'on estime qu'il est plus logique de représenter un thread comme un objet ou bien comme une entité complètement différente, c'est-à-dire un processus. (68) Si l'on choisit d'y penser comme à un processus, alors on se libère de l'impératif orienté objet selon lequel « tout est objet». Cela signifie aussi qu'il n'y a pas de raison de rendre toute la classe Runnable, si l'on veut seulement démarrer un processus pour piloter une partie d'un programme. C'est pourquoi il est souvent plus logique de cacher le code des threads à l'intérieur d'une classe en utilisant une classe interne, comme indiqué ici :

//: c13:ThreadVariations.java
// Création de threads avec des classes internes.
import com.bruceeckel.simpletest.*;

// Utilisation d'une classe interne nommée :
class InnerThread1 {
    private int countDown = 5;
    private Inner inner;
    private class Inner extends Thread {
        Inner(String name) {
            super(name);
            start();
        }
        public void run() {
            while(true) {
                System.out.println(this);
                if(--countDown == 0) return;
                try {
                    sleep(10);
                } catch (InterruptedException e) {
                    throw new RuntimeException(e);
                }
            }
        }
        public String toString() {
            return getName() + ": " + countDown;
        }
    }
    public InnerThread1(String name) {
        inner = new Inner(name);
    }
}

// Utilisation d'une classe interne anonyme :
class InnerThread2 {
    private int countDown = 5;
    private Thread t;
    public InnerThread2(String name) {
        t = new Thread(name) {
            public void run() {
                while(true) {
                    System.out.println(this);
                    if(--countDown == 0) return;
                    try {
                        sleep(10);
                    } catch (InterruptedException e) {
                        throw new RuntimeException(e);
                    }
                }
            }
            public String toString() {
                return getName() + ": " + countDown;
            }
        };
        t.start();
    }
}

// Utilisation d'une implémentation nommée de Runnable :
class InnerRunnable1 {
    private int countDown = 5;
    private Inner inner;
    private class Inner implements Runnable {
        Thread t;
        Inner(String name) {
            t = new Thread(this, name);
            t.start();
        }
        public void run() {
            while(true) {
                System.out.println(this);
                if(--countDown == 0) return;
                try {
                    Thread.sleep(10);
                } catch (InterruptedException e) {
                    throw new RuntimeException(e);
                }
            }
        }
        public String toString() {
            return t.getName() + ": " + countDown;
        }
    }
    public InnerRunnable1(String name) {
        inner = new Inner(name);
    }
}

// Utilisation d'une implémentation anonyme de Runnable :
class InnerRunnable2 {
    private int countDown = 5;
    private Thread t;
    public InnerRunnable2(String name) {
        t = new Thread(new Runnable() {
            public void run() {
                while(true) {
                    System.out.println(this);
                    if(--countDown == 0) return;
                    try {
                        Thread.sleep(10);
                    } catch (InterruptedException e) {
                        throw new RuntimeException(e);
                    }
                }
            }
            public String toString() {
                return Thread.currentThread().getName() +
                    ": " + countDown;
            }
        }, name);
        t.start();
    }
}

// Méthode isolée pour exécuter une portion de code en tant que thread :
class ThreadMethod {
    private int countDown = 5;
    private Thread t;
    private String name;
    public ThreadMethod(String name) { this.name = name; }
    public void runThread() {
        if(t == null) {
            t = new Thread(name) {
                public void run() {
                    while(true) {
                        System.out.println(this);
                        if(--countDown == 0) return;
                        try {
                            sleep(10);
                        } catch (InterruptedException e) {
                            throw new RuntimeException(e);
                        }
                    }
                }
                public String toString() {
                    return getName() + ": " + countDown;
                }
            };
            t.start();
        }
    }
}

public class ThreadVariations {
    private static Test monitor = new Test();
    public static void main(String[] args) {
        new InnerThread1("InnerThread1");
        new InnerThread2("InnerThread2");
        new InnerRunnable1("InnerRunnable1");
        new InnerRunnable2("InnerRunnable2");
        new ThreadMethod("ThreadMethod").runThread();
        monitor.expect(new String[] {
            "InnerThread1: 5",
            "InnerThread2: 5",
            "InnerThread2: 4",
            "InnerRunnable1: 5",
            "InnerThread1: 4",
            "InnerRunnable2: 5",
            "ThreadMethod: 5",
            "InnerRunnable1: 4",
            "InnerThread2: 3",
            "InnerRunnable2: 4",
            "ThreadMethod: 4",
            "InnerThread1: 3",
            "InnerRunnable1: 3",
            "ThreadMethod: 3",
            "InnerThread1: 2",
            "InnerThread2: 2",
            "InnerRunnable2: 3",
            "InnerThread2: 1",
            "InnerRunnable2: 2",
            "InnerRunnable1: 2",
            "ThreadMethod: 2",
            "InnerThread1: 1",
            "InnerRunnable1: 1",
            "InnerRunnable2: 1",
            "ThreadMethod: 1"
        }, Test.IGNORE_ORDER + Test.WAIT);
    }
} ///:~

InnerThread1 crée une classe interne nommée qui étend la classe Thread et génère une instance de cette classe interne à l'intérieur de son constructeur. C'est logique quand la classe interne a des fonctionnalités particulières (de nouvelles méthodes) auxquelles on a besoin d'accéder à partir d'autres méthodes. Néanmoins, la plupart du temps on crée un thread pour la simple raison de pouvoir utiliser les fonctionnalités de la classe Thread, il n'est donc pas nécessaire de créer une classe interne nommée. InnerThread2 propose une alternative : une sous-classe interne anonyme de la classe Thread est créée à l'intérieur du constructeur et elle est transtypée vers une référence ascendante à un Thread t. Quand d'autres méthodes de la classe ont besoin d'accéder à t, elles peuvent le faire via l'interface Thread et n'ont pas besoin de connaître le type exact de l'objet.

Les troisième et quatrième classes de l'exemple reproduisent les deux premières classes, mais elles utilisent l'interface Runnable au lieu de la classe Thread. C'est simplement pour montrer que Runnable n'apporte rien de plus dans ce cas, mais est, en fait, un peu plus compliqué à écrire (et à lire). En conséquence, j'incline à utiliser Thread sauf si je suis contraint, d'une manière ou d'une autre, à utiliser Runnable.

La classe ThreadMethod montre la création d'un thread à l'intérieur d'une méthode. On appelle la méthode quand on est prêt à exécuter le thread, et la méthode retourne à l'appelant après le démarrage du thread. Si le thread effectue seulement une opération auxiliaire au lieu d'être un élément fondamental de la classe, c'est probablement une approche plus utile / plus appropriée que de démarrer un thread à l'intérieur du constructeur de la classe.

Comme énoncé précédemment, une des motivations de l'utilisation du mécanisme de thread est de créer une interface utilisateur qui réagit bien. Bien que nous n'abordions pas les interfaces utilisateurs graphiques avant le Chapitre 14, on verra ici un exemple simple d'une interface utilisateur basée sur la console. L'exemple suivant a deux versions : l'une reste bloquée dans un calcul et ne peut donc jamais lire la saisie à la console, la seconde met le calcul à l'intérieur d'un thread et peut donc effectuer le calcul et surveiller la saisie à la console.

//: c13:ResponsiveUI.java
// Bonne réaction de l'interface utilisateur.
import com.bruceeckel.simpletest.*;

class UnresponsiveUI {
    private volatile double d = 1;
    public UnresponsiveUI() throws Exception {
        while(d > 0)
            d = d + (Math.PI + Math.E) / d;
        System.in.read(); // Ligne inaccessible
    }
}

public class ResponsiveUI extends Thread {
    private static Test monitor = new Test();
    private static volatile double d = 1;
    public ResponsiveUI() {
        setDaemon(true);
        start();
    }
    public void run() {
        while(true) {
            d = d + (Math.PI + Math.E) / d;
        }
    }
    public static void main(String[] args) throws Exception {
        //! new UnresponsiveUI(); // Ce processus doit être tué
        new ResponsiveUI();
        Thread.sleep(300);
        System.in.read(); // 'monitor' fournit la saisie
        System.out.println(d); // Montre le déroulement du programme
    }
} ///:~

UnresponsiveUI effectue un calcul à l'intérieur d'une boucle infinie while, elle ne peut donc évidemment jamais atteindre la ligne de saisie à la console (le while conditionnel fait croire au compilateur que la ligne de saisie est accessible). Quand on exécute le programme après avoir ôté le commentaire devant la ligne qui crée UnresponsiveUI, on doit tuer le processus pour en sortir.

Pour que le programme réagisse correctement, on met le calcul à l'intérieur d'une méthode run( ), ce qui permet qu'il soit préempté. Quand on appuie sur la touche Entrée, on voit que le calcul s'exécute effectivement en arrière-plan, tandis que le programme attend la saisie utilisateur (pour le test, la ligne de saisie à la console est fournie automatiquement à System.in.read( ) par l'objet com.bruceeckel.simpletest.Test, expliqué au Chapitre 15).

Soit l'exemple suivant dans lequel la classe « garantit » qu'elle fournira toujours un nombre pair quand on appellera la méthode getValue( ). Néanmoins, il existe un second thread nommé « Watcher » qui appelle sans arrêt getValue( ) et vérifie que cette valeur est vraiment paire. Cela semble une activité inutile, puisqu'il est manifeste en regardant le code que la valeur sera effectivement paire. Mais c'est là qu'on va être surpris. Voici la première version du programme :

//: c13:AlwaysEven.java
// Illustration de conflit entre threads sur des ressources
// lors de la lecture d'un objet en état intermédiaire instable.

public class AlwaysEven {
    private int i;
    public void next() { i++; i++; }
    public int getValue() { return i; }
    public static void main(String[] args) {
        final AlwaysEven ae = new AlwaysEven();
        new Thread("Watcher") {
            public void run() {
                while(true) {
                    int val = ae.getValue();
                    if(val % 2 != 0) {
                        System.out.println(val);
                        System.exit(0);
                    }
                }
            }
        }.start();
        while(true)
            ae.next();
    }
} ///:~

Dans le main( ), on crée un objet AlwaysEven - qui doit être final car on y accède à l'intérieur de la classe anonyme interne définie comme un Thread. Si la valeur lue par le thread n'est pas paire, le thread l'imprime (comme preuve qu'il a capturé l'objet en état instable) puis sort du programme.

Cet exemple illustre un problème fondamental que l'on rencontre lors de l'utilisation de threads. On ne sait jamais à quel moment un thread va s'exécuter. Imaginez que vous êtes assis à table, sur le point de piquer avec votre fourchette le dernier morceau de nourriture restant dans l'assiette, et au moment où votre fourchette l'atteint, la nourriture disparaît soudain (parce que votre thread a été suspendu et qu'un autre thread est venu voler la nourriture). C'est le problème que l'on doit résoudre lorsqu'on écrit des programmes concurrents.

Parfois on ne se soucie pas de savoir si un élément accède à une ressource au moment même où l'on essaie de l'utiliser (la nourriture est dans une autre assiette). Mais pour que le multithreading fonctionne, on a besoin d'un moyen d'éviter que deux threads accèdent à la même ressource, au moins pendant les périodes critiques.

La prévention de ce genre de conflit se résume à poser un verrou sur la ressource quand un thread l'utilise. Le premier thread qui accède à la ressource la verrouille. Les autres threads ne peuvent plus accéder à cette ressource tant qu'elle n'est pas déverrouillée ; dès qu'elle l'est, un autre thread la verrouille et l'utilise, etc. Si le siège avant d'une voiture est la ressource limitée, l'enfant qui crie « Prems ! » active le verrou.

XIII-C-1-a. Un framework qui teste les ressources▲

//: c13:InvariantState.java
// Messager transportant des données invariantes
public interface InvariantState {} ///:~

//: c13:InvariantOK.java
// Indique que le test sur l'invariant a réussi
public class InvariantOK implements InvariantState {} ///:~

//: c13:InvariantFailure.java
// Indique que le test sur l'invariant a échoué

public class InvariantFailure implements InvariantState {
    public Object value;
    public InvariantFailure(Object value) {
        this.value = value;
    }
} ///:~

//: c13:Invariant.java
public interface Invariant {
    InvariantState invariant();
} ///:~

//: c13:Timeout.java
// Fixe une limite temporelle à l'exécution du programme
import java.util.*;

public class Timeout extends Timer {
    public Timeout(int delay, final String msg) {
        super(true); // Thread démon
        schedule(new TimerTask() {
            public void run() {
                System.out.println(msg);
                System.exit(0);
            }
        }, delay);
    }
} ///:~

//: c13:InvariantWatcher.java
// Vérifie constamment que l'invariant n'est pas violé

public class InvariantWatcher extends Thread {
    private Invariant invariant;
    public InvariantWatcher(Invariant invariant) {
        this.invariant = invariant;
        setDaemon(true);
        start();
    }
    // S'arrête après un moment :
    public
    InvariantWatcher(Invariant invariant, final int timeOut){
        this(invariant);
        new Timeout(timeOut,
            "Délai expiré sans violation de l'invariant");
    }
    public void run() {
        while(true) {
            InvariantState state = invariant.invariant();
            if(state instanceof InvariantFailure) {
                System.out.println("Invariant violé : "
                    + ((InvariantFailure)state).value);
                System.exit(0);
            }
        }
    }
} ///:~

//: c13:EvenGenerator.java
// AlwaysEven.java utilisant le testeur d'invariance

public class EvenGenerator implements Invariant {
    private int i;
    public void next() { i++; i++; }
    public int getValue() { return i; }
    public InvariantState invariant() {
        int val = i; // On la stocke au cas où elle changerait
        if(val % 2 == 0)
            return new InvariantOK();
        else
            return new InvariantFailure(new Integer(val));
    }
    public static void main(String[] args) {
        EvenGenerator gen = new EvenGenerator();
        new InvariantWatcher(gen);
        while(true)
            gen.next();
    }
} ///:~

The worst thing that happens with EvenGenerator is that a client thread might see it in an unstable intermediate state. The object's internal consistency is maintained, however, and it eventually becomes visible in a good state. But if two threads are actually modifying an object, the contention over shared resources is much worse, because the object can be put into an incorrect state.

Consider the simple concept of a semaphore, which is a flag object used for communication between threads. If the semaphore's value is zero, then whatever it is monitoring is available, but if the value is nonzero, then the monitored entity is unavailable, and the thread must wait for it. When it's available, the thread increments the semaphore and then goes ahead and uses the monitored entity. Because incrementing and decrementing are atomic operations (that is, they cannot be interrupted), the semaphore keeps two threads from using the same entity at the same time.

If the semaphore is going to properly guard the entity that it is monitoring, then it must never get into an unstable state. Here's a simple version of the semaphore idea:

//: c13:Semaphore.java
// A simple threading flag

public class Semaphore implements Invariant {
    private volatile int semaphore = 0;
    public boolean available() { return semaphore == 0; }
    public void acquire() { ++semaphore; }
    public void release() { --semaphore; }
    public InvariantState invariant() {
        int val = semaphore;
        if(val == 0 || val == 1)
            return new InvariantOK();
        else
            return new InvariantFailure(new Integer(val));
    }
} ///:~

The core part of the class is straightforward, consisting of available( ), acquire( ), and release( ). Since a thread should check for availability before acquiring, the value of semaphore should never be other than one or zero, and this is tested by invariant( ).

But look what happens when Semaphore is tested for thread consistency:

//: c13:SemaphoreTester.java
// Colliding over shared resources

public class SemaphoreTester extends Thread {
    private volatile Semaphore semaphore;
    public SemaphoreTester(Semaphore semaphore) {
        this.semaphore = semaphore;
        setDaemon(true);
        start();
    }
    public void run() {
        while(true)
            if(semaphore.available()) {
                yield(); // Makes it fail faster
                semaphore.acquire();
                yield();
                semaphore.release();
                yield();
            }
    }
    public static void main(String[] args) throws Exception {
        Semaphore sem = new Semaphore();
        new SemaphoreTester(sem);
        new SemaphoreTester(sem);
        new InvariantWatcher(sem).join();
    }
} ///:~

The SemaphoreTester creates a thread that continuously tests to see if a Semaphore object is available, and if so acquires and releases it. Note that the semaphore field is volatile to make sure that the compiler doesn't optimize away any reads of that value.

In main( ), two SemaphoreTester threads are created, and you'll see that in short order the invariant is violated. This happens because one thread might get a true result from calling available( ), but by the time that thread calls acquire( ), the other thread may have already called acquire( ) and incremented the semaphore field. The InvariantWatcher may see the field with too high a value, or possibly see it after both threads have called release( ) and decremented it to a negative value. Note that InvariantWatcher join( )s with the main thread to keep the program running until there is a failure.

On my machine, I discovered that the inclusion of yield( ) caused failure to occur much faster, but this will vary with operating systems and JVM implementations. You should experiment with taking the yield( ) statements out; the failure might take a very long time to occur, which demonstrates how difficult it can be to detect a flaw in your program when you're writing multithreaded code.

This class emphasizes the risk of concurrent programming: If a class this simple can produce problems, you can never trust any assumptions about concurrency.

To solve the problem of thread collision, virtually all multithreading schemes serialize access to shared resources. This means that only one thread at a time is allowed to access the shared resource. This is ordinarily accomplished by putting a locked clause around a piece of code so that only one thread at a time may pass through that piece of code. Because this locked clause produces mutual exclusion, a common name for such a mechanism is mutex.

Consider the bathroom in your house; multiple people (threads) may each want to have exclusive use of the bathroom (the shared resource). To access the bathroom, a person knocks on the door to see if it's available. If so, they enter and lock the door. Any other thread that wants to use the bathroom is « blocked » from using it, so that thread waits at the door until the bathroom is available.

The analogy breaks down a bit when the bathroom is released and it comes time to give access to another thread. There isn't actually a line of people and we don't know for sure who gets the bathroom next, because the thread scheduler isn't deterministic that way. Instead, it's as if there is a group of blocked threads milling about in front of the bathroom, and when the thread that has locked the bathroom unlocks it and emerges, the one that happens to be nearest the door at the moment goes in. As noted earlier, suggestions can be made to the thread scheduler via yield( ) and setPriority( ), but these suggestions may not have much of an effect depending on your platform and JVM implementation.

Java has built-in support to prevent collisions over resources in the form of the synchronized keyword. This works much like the Semaphore class was supposed to: When a thread wishes to execute a piece of code guarded by the synchronized keyword, it checks to see if the semaphore is available, then acquires it, executes the code, and releases it. However, synchronized is built into the language, so it's guaranteed to always work, unlike the Semaphore class.

The shared resource is typically just a piece of memory in the form of an object, but may also be a file, I/O port, or something like a printer. To control access to a shared resource, you first put it inside an object. Then any method that accesses that resource can be made synchronized. This means that if a thread is inside one of the synchronized methods, all other threads are blocked from entering any of the synchronized methods of the class until the first thread returns from its call.

Since you typically make the data elements of a class private and access that memory only through methods, you can prevent collisions by making methods synchronized. Here is how you declare synchronized methods:

synchronized void f() { /* ... */ }
synchronized void g(){ /* ... */ }

Each object contains a single lock (also referred to as a monitor)that is automatically part of the object (you don't have to write any special code). When you call any synchronized method, that object is locked and no other synchronized method of that object can be called until the first one finishes and releases the lock. In the preceding example, if f( ) is called for an object, g( ) cannot be called for the same object until f( ) is completed and releases the lock. Thus, there is a single lock that is shared by all the synchronized methods of a particular object, and this lock prevents common memory from being written by more than one thread at a time.

One thread may acquire an object's lock multiple times. This happens if one method calls a second method on the same object, which in turn calls another method on the same object, etc. The JVM keeps track of the number of times the object has been locked. If the object is unlocked, it has a count of zero. As a thread acquires the lock for the first time, the count goes to one. Each time the thread acquires a lock on the same object, the count is incremented. Naturally, multiple lock acquisition is only allowed for the thread that acquired the lock in the first place. Each time the thread leaves a synchronized method, the count is decremented, until the count goes to zero, releasing the lock entirely for use by other threads.

There's also a single lock per class (as part of the Class object for the class), so that synchronized static methods can lock each other out from simultaneous access of static data on a class-wide basis.

XIII-C-3-a. Synchronizing the EvenGenerator▲

//: c13:SynchronizedEvenGenerator.java
// Using "synchronized" to prevent thread collisions

public
class SynchronizedEvenGenerator implements Invariant {
    private int i;
    public synchronized void next() { i++; i++; }
    public synchronized int getValue() { return i; }
    // Not synchronized so it can run at
    // any time and thus be a genuine test:
    public InvariantState invariant() {
        int val = getValue();
        if(val % 2 == 0)
            return new InvariantOK();
        else
            return new InvariantFailure(new Integer(val));
    }
    public static void main(String[] args) {
        SynchronizedEvenGenerator gen =
            new SynchronizedEvenGenerator();
        new InvariantWatcher(gen, 4000); // 4-second timeout
        while(true)
            gen.next();
    }
} ///:~

XIII-C-3-b. Atomic operations▲

public synchronized int getValue() { return i; }

//: c13:SerialNumberGenerator.java

public class SerialNumberGenerator {
    private static volatile int serialNumber = 0;
    public static int nextSerialNumber() {
        return serialNumber++;
    }
} ///:~

//: c13:SerialNumberChecker.java
// Operations that may seem safe are not,
// when threads are present.

// Reuses storage so we don't run out of memory:
class CircularSet {
    private int[] array;
    private int len;
    private int index = 0;
    public CircularSet(int size) {
        array = new int[size];
        len = size;
        // Initialize to a value not produced
        // by the SerialNumberGenerator:
        for(int i = 0; i < size; i++)
            array[i] = -1;
    }
    public synchronized void add(int i) {
        array[index] = i;
        // Wrap index and write over old elements:
        index = ++index % len;
    }
    public synchronized boolean contains(int val) {
        for(int i = 0; i < len; i++)
            if(array[i] == val) return true;
                return false;
    }
}

public class SerialNumberChecker {
    private static CircularSet serials =
        new CircularSet(1000);
    static class SerialChecker extends Thread {
        SerialChecker() { start(); }
        public void run() {
            while(true) {
                int serial =
                    SerialNumberGenerator.nextSerialNumber();
                if(serials.contains(serial)) {
                    System.out.println("Duplicate: " + serial);
                    System.exit(0);
                }
                serials.add(serial);
            }
        }
    }
    public static void main(String[] args) {
        for(int i = 0; i < 10; i++)
            new SerialChecker();
        // Stop after 4 seconds:
        new Timeout(4000, "No duplicates detected");
    }
} ///:~

XIII-C-3-c. Fixing Semaphore▲

//: c13:SynchronizedSemaphore.java
// Colliding over shared resources

public class SynchronizedSemaphore extends Semaphore {
    private volatile int semaphore = 0;
    public synchronized boolean available() {
        return semaphore == 0;
    }
    public synchronized void acquire() { ++semaphore; }
    public synchronized void release() { --semaphore; }
    public InvariantState invariant() {
        int val = semaphore;
        if(val == 0 || val == 1)
            return new InvariantOK();
        else
            return new InvariantFailure(new Integer(val));
    }
    public static void main(String[] args) throws Exception {
        SynchronizedSemaphore sem =new SynchronizedSemaphore();
        new SemaphoreTester(sem);
        new SemaphoreTester(sem);
        new InvariantWatcher(sem).join();
    }
} ///:~

Sometimes, you only want to prevent multiple thread access to part of the code inside a method instead of the entire method. The section of code you want to isolate this way is called a critical section and is also created using the synchronized keyword. Here, synchronized is used to specify the object whose lock is being used to synchronize the enclosed code:

synchronized(syncObject) {
    // This code can be accessed 
    // by only one thread at a time
}

This is also called a synchronized block; before it can be entered, the lock must be acquired on syncObject. If some other thread already has this lock, then the critical section cannot be entered until the lock is given up.

The following example compares both approaches to synchronization by showing how the time available for other threads to access an object is significantly increased by using a synchronized block instead of synchronizing an entire method. In addition, it shows how an unprotected class can be used in a multithreaded situation if it is controlled and protected by another class:

//: c13:CriticalSection.java
// Synchronizing blocks instead of entire methods. Also
// demonstrates protection of a non-thread-safe class
// with a thread-safe one.
import java.util.*;

class Pair { // Not thread-safe
    private int x, y;
    public Pair(int x, int y) {
        this.x = x;
        this.y = y;
    }
    public Pair() { this(0, 0); }
    public int getX() { return x; }
    public int getY() { return y; }
    public void incrementX() { x++; }
    public void incrementY() { y++; }
    public String toString() {
        return "x: " + x + ", y: " + y;
    }
    public class PairValuesNotEqualException
            extends RuntimeException {
        public PairValuesNotEqualException() {
            super("Pair values not equal: " + Pair.this);
        }
    }
    // Arbitrary invariant -- both variables must be equal:
    public void checkState() {
        if(x != y)
            throw new PairValuesNotEqualException();
    }
}

// Protect a Pair inside a thread-safe class:
abstract class PairManager {
    protected Pair p = new Pair();
    private List storage = new ArrayList();
    public synchronized Pair getPair() {
        // Make a copy to keep the original safe:
        return new Pair(p.getX(), p.getY());
    }
    protected void store() { storage.add(getPair()); }
    // A "template method":
    public abstract void doTask();
}

// Synchronize the entire method:
class PairManager1 extends PairManager {
    public synchronized void doTask() {
        p.incrementX();
        p.incrementY();
        store();
    }
}

// Use a critical section:
class PairManager2 extends PairManager {
    public void doTask() {
        synchronized(this) {
            p.incrementX();
            p.incrementY();
        }
        store();
    }
}

class PairManipulator extends Thread {
    private PairManager pm;
    private int checkCounter = 0;
    private class PairChecker extends Thread {
        PairChecker() { start(); }
        public void run() {
            while(true) {
                checkCounter++;
                pm.getPair().checkState();
            }
        }
    }
    public PairManipulator(PairManager pm) {
        this.pm = pm;
        start();
        new PairChecker();
    }
    public void run() {
        while(true) {
            pm.doTask();
        }
    }
    public String toString() {
        return "Pair: " + pm.getPair() +
            " checkCounter = " + checkCounter;
    }
}

public class CriticalSection {
    public static void main(String[] args) {
        // Test the two different approaches:
        final PairManipulator
            pm1 = new PairManipulator(new PairManager1()),
            pm2 = new PairManipulator(new PairManager2());
        new Timer(true).schedule(new TimerTask() {
            public void run() {
                System.out.println("pm1: " + pm1);
                System.out.println("pm2: " + pm2);
                System.exit(0);
            }
        }, 500); // run() after 500 milliseconds
    }
} ///:~

As noted, Pair is not thread-safe because its invariant (admittedly arbitrary) requires that both variables maintain the same values. In addition, as seen earlier in this chapter, the increment operations are not thread-safe, and because none of the methods are synchronized, you can't trust a Pair object to stay uncorrupted in a threaded program.

The PairManager class holds a Pair object and controls all access to it. Note that the only public methods are getPair( ), which is synchronized, and the abstract doTask( ). Synchronization for this method will be handled when it is implemented.

The structure of PairManager, where some of the functionality is implemented in the base class with one or more abstract methods defined in derived classes, is called a Template Method in Design Patterns parlance. (71) Design patterns allow you to encapsulate change in your code; here, the part that is changing is the template method doTask( ). In PairManager1 the entire doTask( ) is synchronized, but in PairManager2 only part of doTask( ) is synchronized by using a synchronized block. Note that the synchronized keyword is not part of the method signature and thus may be added during overriding.

PairManager2 is observing, in effect, that store( ) is a protected method and thus is not available to the general client, but only to subclasses. Thus, it doesn't necessarily need to be guarded inside a synchronized method, and is instead placed outside of the synchronized block.

A synchronized block must be given an object to synchronize upon, and usually the most sensible object to use is just the current object that the method is being called for: synchronized(this), which is the approach taken in PairManager2. That way, when the lock is acquired for the synchronized block, other synchronized methods in the object cannot be called. So the effect is that of simply reducing the scope of synchronization.

Sometimes this isn't what you want, in which case you can create a separate object and synchronize on that. The following example demonstrates that two threads can enter an object when the methods in that object synchronize on different locks:

//: c13:SyncObject.java
// Synchronizing on another object
import com.bruceeckel.simpletest.*;

class DualSynch {
    private Object syncObject = new Object();
    public synchronized void f() {
        System.out.println("Inside f()");
        // Doesn't release lock:
        try {
            Thread.sleep(500);
        } catch(InterruptedException e) {
            throw new RuntimeException(e);
        }
        System.out.println("Leaving f()");
    }
    public void g() {
        synchronized(syncObject) {
            System.out.println("Inside g()");
            try {
                Thread.sleep(500);
            } catch(InterruptedException e) {
                throw new RuntimeException(e);
            }
            System.out.println("Leaving g()");
        }
    }
}

public class SyncObject {
    private static Test monitor = new Test();
    public static void main(String[] args) {
        final DualSynch ds = new DualSynch();
        new Thread() {
            public void run() {
                ds.f();
            }
        }.start();
        ds.g();
        monitor.expect(new String[] {
            "Inside g()",
            "Inside f()",
            "Leaving g()",
            "Leaving f()"
        }, Test.WAIT + Test.IGNORE_ORDER);
    }
} ///:~

The DualSync method f( ) synchronizes on this (by synchronizing the entire method) and g( ) has a synchronized block that synchronizes on syncObject. Thus, the two synchronizations are independent. This is demonstrated in main( ) by creating a Thread that calls f( ). The main( ) thread is used to call g( ). You can see from the output that both methods are running at the same time, so neither one is blocked by the synchronization of the other.

Returning to CriticalSection.java, PairManipulator is created to test the two different types of PairManager by running doTask( ) in one thread and an instance of the inner class PairChecker in the other. To trace how often it is able to run the test, PairChecker increments checkCounter every time it is successful. In main( ), two PairManipulator objects are created and allowed to run for awhile. When the Timer runs out, it executes its run( ) method, that displays the results of each PairManipulator and exits. When you run the program, you should see something like this:

pm1: Pair: x: 58892, y: 58892 checkCounter = 44974
pm2: Pair: x: 73153, y: 73153 checkCounter = 100535

Although you will probably see a lot of variation from one run to the next, in general you will see that PairManager1.doTask( ) does not allow the PairChecker nearly as much access as PairManager2.doTask( ), which has the synchronized block and thus provides more unlocked time. This is typically the reason that you want to use a synchronized block instead of synchronizing the whole method: to allow other threads more access (as long as it is safe to do so).

Of course, all synchronization depends on programmer diligence: Every piece of code that can access a shared resource must be wrapped in an appropriate synchronized block.

Quand un thread est bloqué, il y a une raison pour qu'il ne continue pas son exécution. Un thread peut devenir bloqué pour les raisons suivantes :

• Vous avez mis le thread à dormir en appelant sleep(milliseconds), auquel cas il ne tournera pas pendant le temps spécifié.
• Vous avez suspendu l'exécution du thread avec wait( ). Il ne redeviendra pas exécutable avant que le thread ne reçoive le message notify( ) ou notifyAll( ). Nous allons les examiner dans la prochaine section.
• Le thread attend la fin d'une I/O.
• Le thread essaye d'appeler une méthode synchronized sur un autre objet et le verrou de cet objet n'est pas libre.

Dans du vieux code, vous pouvez également voir suspend( ) et resume( ) utilisés pour bloquer et débloquer des threads, mais ceux-ci sont dépréciés dans Java 2 (parce qu'ils ont tendance à donner des impasses) et ne seront donc pas examinés dans ce livre.

It's important to understand that sleep( ) does not release the lock when it is called. On the other hand, the method wait( ) does release the lock, which means that other synchronized methods in the thread object can be called during a wait( ). When a thread enters a call to wait( ) inside a method, that thread's execution is suspended, and the lock on that object is released.

There are two forms of wait( ). The first takes an argument in milliseconds that has the same meaning as in sleep( ): « Pause for this period of time. » The difference is that in wait( ):

• The object lock is released during the wait( ).
• You can come out of the wait( ) due to a notify( ) or notifyAll( ),or by letting the clock run out.

The second form of wait( ) takes no arguments; this version is more commonly used. This wait( ) continues indefinitely until the thread receives a notify( ) or notifyAll( ).

One fairly unique aspect of wait( ), notify( ), and notifyAll( ) is that these methods are part of the base class Object and not part of Thread, as is sleep( ). Although this seems a bit strange at first-to have something that's exclusively for threading as part of the universal base class-it's essential because they manipulate the lock that's also part of every object. As a result, you can put a wait( ) inside any synchronized method, regardless of whether that class extends Thread or implements Runnable. In fact, the only place you can call wait( ), notify( ), or notifyAll( ) is within a synchronized method or block (sleep( ) can be called within non-synchronized methods since it doesn't manipulate the lock). If you call any of these within a method that's not synchronized, the program will compile, but when you run it, you'll get an IllegalMonitorStateException with the somewhat nonintuitive message « current thread not owner. » This message means that the thread calling wait( ), notify( ), or notifyAll( ) must « own » (acquire) the lock for the object before it can call any of these methods.

You can ask another object to perform an operation that manipulates its own lock. To do this, you must first capture that object's lock. For example, if you want to notify( ) an object x, you must do so inside a synchronized block that acquires the lock for x:

synchronized(x) {
    x.notify();
}

Typically, wait( ) is used when you're waiting for some condition that is under the control of forces outside of the current method to change (typically, this condition will be changed by another thread). You don't want to idly wait while testing the condition inside your thread; this is called a « busy wait » and it's a very bad use of CPU cycles. So wait( ) allows you to put the thread to sleep while waiting for the world to change, and only when a notify( ) or notifyAll( ) occurs does the thread wake up and check for changes. Thus, wait( ) provides a way to synchronize activities between threads.

As an example, consider a restaurant that has one chef and one waitperson. The waitperson must wait for the chef to prepare a meal. When the chef has a meal ready, the chef notifies the waitperson, who then gets the meal and goes back to waiting. This is an excellent example of thread cooperation: The chef represents the producer, and the waitperson represents the consumer. Here is the story modeled in code:

//: c13:Restaurant.java
// The producer-consumer approach to thread cooperation.
import com.bruceeckel.simpletest.*;

class Order {
    private static int i = 0;
    private int count = i++;
    public Order() {
        if(count == 10) {
            System.out.println("Out of food, closing");
            System.exit(0);
        }
    }
    public String toString() { return "Order " + count; }
}

class WaitPerson extends Thread {
    private Restaurant restaurant;
    public WaitPerson(Restaurant r) {
        restaurant = r;
        start();
    }
    public void run() {
        while(true) {
            while(restaurant.order == null)
                synchronized(this) {
                    try {
                        wait();
                    } catch(InterruptedException e) {
                        throw new RuntimeException(e);
                    }
                }
            System.out.println(
                "Waitperson got " + restaurant.order);
            restaurant.order = null;
        }
    }
}

class Chef extends Thread {
    private Restaurant restaurant;
    private WaitPerson waitPerson;
    public Chef(Restaurant r, WaitPerson w) {
        restaurant = r;
        waitPerson = w;
        start();
    }
    public void run() {
        while(true) {
            if(restaurant.order == null) {
                restaurant.order = new Order();
                System.out.print("Order up! ");
                synchronized(waitPerson) {
                    waitPerson.notify();
                }
            }
            try {
                sleep(100);
            } catch(InterruptedException e) {
                throw new RuntimeException(e);
            }
        }
    }
}

public class Restaurant {
    private static Test monitor = new Test();
    Order order; // Package access
    public static void main(String[] args) {
        Restaurant restaurant = new Restaurant();
        WaitPerson waitPerson = new WaitPerson(restaurant);
        Chef chef = new Chef(restaurant, waitPerson);
        monitor.expect(new String[] {
            "Order up! Waitperson got Order 0",
            "Order up! Waitperson got Order 1",
            "Order up! Waitperson got Order 2",
            "Order up! Waitperson got Order 3",
            "Order up! Waitperson got Order 4",
            "Order up! Waitperson got Order 5",
            "Order up! Waitperson got Order 6",
            "Order up! Waitperson got Order 7",
            "Order up! Waitperson got Order 8",
            "Order up! Waitperson got Order 9",
            "Out of food, closing"
        }, Test.WAIT);
    }
} ///:~

Order is a simple self-counting class, but notice that it also includes a way to terminate the program; on order 10, System.exit( ) is called.

A WaitPerson must know what Restaurant they are working for because they must fetch the order from the restaurant's « order window, » restaurant.order. In run( ), the WaitPerson goes into wait( ) mode, stopping that thread until it is woken up with a notify( ) from the Chef. Since this is a very simple program, we know that only one thread will be waiting on the WaitPerson's lock: the WaitPerson thread itself. For this reason it's safe to call notify( ). In more complex situations, multiple threads may be waiting on a particular object lock, so you don't know which thread should be awakened. The solutions is to call notifyAll( ), which wakes up all the threads waiting on that lock. Each thread must then decide whether the notification is relevant.

Notice that the wait( ) is wrapped in a while( ) statement that is testing for the same thing that is being waited for. This seems a bit strange at first-if you're waiting for an order, once you wake up the order must be available, right? The problem is that in a multithreading application, some other thread might swoop in and grab the order while the WaitPerson is waking up. The only safe approach is to always use the following idiom for a wait( ):

while(conditionIsNotMet)
wait( );

This guarantees that the condition will be met before you get out of the wait loop, and if you have either been notified of something that doesn't concern the condition (as can happen with notifyAll( )), or the condition changes before you get fully out of the wait loop, you are guaranteed to go back into waiting.

A Chef object must know what restaurant he or she is working for (so the Orders can be placed in restaurant.order)and the WaitPerson who is picking up the meals, so that WaitPerson can be notified when an order is ready. In this simplified example, the Chef is generating the Order objects, then notifying the WaitPerson that an order is ready.

Observe that the call to notify( ) must first capture the lock on waitPerson. The call to wait( ) in WaitPerson.run( ) automatically releases the lock, so this is possible. Because the lock must be owned in order to call notify( ), it's guaranteed that two threads trying to call notify( ) on one object won't step on each other's toes.

The preceding example has only a single spot for one thread to store an object so that another thread can later use that object. However, in a typical producer-consumer implementation, you use a first-in, first-out queue in order to store the objects being produced and consumed. See the exercises at the end of the chapter to learn more about this.

It's often useful for threads to communicate with each other by using I/O. Threading libraries may provide support for interthread I/O in the form of pipes. These exist in the Java I/O library as the classes PipedWriter (which allows a thread to write into a pipe) and PipedReader (which allows a different thread to read from the same pipe). This can be thought of as a variation of the producer-consumer problem, where the pipe is the canned solution.

Here's a simple example in which two threads use a pipe to communicate:

//: c13:PipedIO.java
// Using pipes for inter-thread I/O
import java.io.*;
import java.util.*;

class Sender extends Thread {
    private Random rand = new Random();
    private PipedWriter out = new PipedWriter();
    public PipedWriter getPipedWriter() { return out; }
    public void run() {
        while(true) {
            for(char c = 'A'; c <= 'z'; c++) {
                try {
                    out.write(c);
                    sleep(rand.nextInt(500));
                } catch(Exception e) {
                    throw new RuntimeException(e);
                }
            }
        }
    }
}

class Receiver extends Thread {
    private PipedReader in;
    public Receiver(Sender sender) throws IOException {
        in = new PipedReader(sender.getPipedWriter());
    }
    public void run() {
        try {
            while(true) {
                // Blocks until characters are there:
                System.out.println("Read: " + (char)in.read());
            }
        } catch(IOException e) {
            throw new RuntimeException(e);
        }
    }
}

public class PipedIO {
    public static void main(String[] args) throws Exception {
        Sender sender = new Sender();
        Receiver receiver = new Receiver(sender);
        sender.start();
        receiver.start();
        new Timeout(4000, "Terminated");
    }
} ///:~

Sender and Receiver represent threads that are performing some tasks and need to communicate with each other. Sender creates a PipedWriter, which is a standalone object, but inside Receiver the creation of PipedReader must be associated with a PipedWriter in the constructor. The Sender puts data into the Writer and sleeps for a random amount of time. However, Receiver has no sleep( ) or wait( ). But when it does a read( ), it automatically blocks when there is no more data. You get the effect of a producer-consumer, but no wait( ) loop is necessary.

Notice that the sender and receiver are started in main( ), after the objects are completely constructed. If you don't start completely constructed objects, the pipe can produce inconsistent behavior on different platforms.

Only the most basic cooperation approach (producer-consumer, usually implemented with wait( ) and notify( )/notifyAll( )) has been introduced in this section. This will solve most kinds of thread cooperation problems, but there are numerous more sophisticated approaches that are described in more advanced texts (in particular, Lea, noted at the end of this chapter).