Programme principal

Tous les programmes Java que vous avez écrits jusqu'ici n'étaient constitués que d'un seul fil d'exécution, généralement nommé le fil principal (main thread). Il est toutefois possible de créer plusieurs fils indépendants au sein d'un seul et même programme, comme nous allons l'illustrer.

Pour ce faire, nous utiliserons un programme d'exemple, dont la première version est tout à fait classique et ne comporte qu'un seul fil d'exécution :

public final class ThreadsExample {
  static void main() {
    print26('a');
    print26('A');
    System.out.print('_');
  }

  private static void print26(char c) {
    for (int i = 0; i < 26; i++)
      System.out.print((char)(c + i));
  }
}

Lorsqu'on exécute ce programme, il affiche la ligne ci-dessous, le premier appel à print26 affichant l'alphabet en minuscule, le second affichant l'alphabet en majuscule, et le dernier appel à print affichant un caractère souligné (_) :

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ_

On peut maintenant modifier ce programme pour faire en sorte que chacun des appels à print26 soit fait par un fil d'exécution séparé, représenté par une instance de Thread. La lambda passée à la méthode startVirtualThread contient le code que le fil doit exécuter.

public final class ThreadsExample {
  static void main() throws Exception {
    Thread t1 = Thread.startVirtualThread(() -> print26('a'));
    Thread t2 = Thread.startVirtualThread(() -> print26('A'));
    System.out.print('_');
    t1.join(); t2.join(); // attend que t1 et t2 terminent
  }
  // … print26 identique à avant
}

Lorsqu'on exécute cette version modifiée du programme, trois fils d'exécution fonctionnent en parallèle : le fil principal, qui crée et démarre chacun des deux fils auxiliaires puis affiche un caractère souligné ; le premier fil auxiliaire, t1, qui affiche l'alphabet en minuscule ; et le second fil auxiliaire, t2, qui affiche l'alphabet en majuscule.

Étant donné que ces trois fils s'exécutent en parallèle, il est possible que l'alphabet minuscule, l'alphabet majuscule et le caractère souligné soient entrelacés de manière arbitraire, plutôt que d'être affichés dans cet ordre comme initialement. On peut observer cela en exécutant plusieurs fois le programme ci-dessus. Ainsi les lignes suivantes ont été obtenues en le lançant dix fois de suite :

ab_ABCDEFGHIJKLMNOPQRSTUVWXYZcdefghijklmnopqrstuvwxyz
abcdefghijklmnopqrstuvwxyz_ABCDEFGHIJKLMNOPQRSTUVWXYZ
abcdefghijklmnopqrstuv_ABCDEFGHIJKLMNOPQRSTUVWXYZwxyz
abc_ABCDEFGHIJKLMNOPQRSTUVWXYZdefghijklmnopqrstuvwxyz
abcdefgh_ABCDEFGHIJKijkLMNOPQRSTUVWXYZlmnopqrstuvwxyz
abcd_ABCDEFGHIJKLMNOPQRSTUVWXYZefghijklmnopqrstuvwxyz
ab_ABCDEFGcdefghijklmnopqrstuvwHIJKLMNOPQRxyzSTUVWXYZ
abc_ABCDEFGHIJKLMNOPQRSTUVWXYZdefghijklmnopqrstuvwxyz
abcde_ABCDEFGHIJKLMNOPQRSTUVWXYZfghijklmnopqrstuvwxyz
ab_ABCDEFGHIJKLMNOPQRSTUVWXYZcdefghijklmnopqrstuvwxyz

Comme on le voit, différentes exécutions peuvent donner des résultats différents, car chaque fil procède de manière indépendante, à son propre rythme. Il est toutefois important de comprendre que chacun des fils s'exécute de manière séquentielle, comme d'habitude. Donc les lettres des alphabets minuscule et majuscule apparaissent toujours dans le bon ordre. Ce qui varie est l'entrelacement des deux alphabets et du caractère souligné.

Au démarrage d'une application JavaFX, un fil d'exécution nommé le fil (d'application) JavaFX (JavaFX [Application] Thread) est automatiquement créé par la méthode launch. C'est ce fil qui se charge ensuite d'appeler la méthode start.

Le fil JavaFX a pour but de gérer l'interface graphique, et c'est donc lui qui exécute, par exemple, tous les gestionnaires d'événement attachés au graphe de scène. Il faut de plus impérativement que ce soit lui qui exécute la totalité du code modifiant l'interface graphique. Il est très important de se souvenir de cela, car le non-respect de cette règle produit des plantages difficiles à diagnostiquer. De plus, il faut aussi être conscient du fait que tout blocage du fil JavaFX provoque un blocage de l'interface graphique. Il ne faut donc jamais bloquer ce fil pour une durée indéterminée.

Pour Ajul, nous utiliserons deux fils d'exécution :

• le fil JavaFX, créé automatiquement comme nous l'avons dit,
• le fil chargé de gérer la partie, créé par nos soins.

L'existence de ces deux fils d'exécution présente un risque qui n'existe pas dans les programmes n'en utilisant qu'un, lié aux valeurs non immuables partagées entre eux. En effet, lorsqu'une valeur non immuable est partagée entre deux fils d'exécution, et qu'elle n'a pas été prévue pour cela — en anglais, on dit qu'elle n'est pas thread-safe — elle peut être corrompue en cas de modification simultanée.

Pour comprendre cela, imaginons une liste de type ArrayList — classe qui n'est pas thread-safe — partagée entre deux fils d'exécution. Supposons que la liste soit vide, et que chaque fil désire y ajouter un élément. Le premier fil lit la taille actuelle (0) et place son élément à la position 0 ; à cet instant précis, le second fil fait de même, lit la taille actuelle (toujours 0) et place son élément à la position 0, écrasant celui du premier fil, avant d'incrémenter la taille, qui vaut alors 1 ; finalement, le premier fil termine son ajout en incrémentant la taille, qui vaut alors 2. La liste est alors corrompue, l'un des éléments ayant écrasé l'autre.

Pour éviter ce genre de problèmes — très difficiles à reproduire et à diagnostiquer, car dépendant de l'entrelacement exact des exécutions des deux fils, qui varie d'une exécution à l'autre — il ne faut partager entre plusieurs fils d'exécution que des valeurs qui sont soit immuables, soit thread-safe. C'est ce que nous ferons dans ce projet, en nous efforçant de plus de limiter le nombre de valeurs partagées entre les deux fils.

L'une des valeurs — non immuable, mais thread-safe — que les deux fils d'exécution d'Ajul partageront aura pour but de les synchroniser. Cela est nécessaire car, lorsque c'est à un joueur humain de jouer, le fil chargé de gérer la partie doit attendre que le joueur en question ait choisi le coup qu'il désire jouer en interagissant avec l'interface graphique.

Nous utiliserons pour cela une file bloquante bornée (bounded blocking queue), similaire à une file normale si ce n'est que :

• lorsqu'un fil d'exécution essaie de retirer un élément d'une telle file alors qu'elle est vide, il est bloqué jusqu'à ce qu'un élément y soit ajouté par un autre fil,
• lorsqu'un fil d'exécution essaie d'ajouter un élément à une telle file alors qu'elle est pleine, il est bloqué jusqu'à ce qu'un élément en soit retiré par un autre fil.

Dans notre cas, la file contiendra le coup joué par le joueur humain. Le fil gérant la partie bloquera en attendant que le fil JavaFX y place le coup joué par le joueur humain.