Exclusion mutuelle sur monoprocesseurs¶

Même si les threads sont très utiles dans des ordinateurs multiprocesseurs, ils ont été inventés et utilisés d’abord sur des processeurs capables d’exécuter un seul thread d’exécution à la fois. Sur un tel processeur, les threads d’exécution sont entrelacés plutôt que d’être exécutés réellement simultanément. Cet entrelacement est réalisé par le système d’exploitation.

Les systèmes d’exploitation de la famille Unix permettent d’exécuter plusieurs programmes en même temps sur un ordinateur, même si il est équipé d’un processeur qui n’est capable que d’exécuter un thread à la fois. Cette fonctionnalité est souvent appelée la multiprogrammation ou le multitâche (ou multitasking en anglais). Cette exécution simultanée de plusieurs programmes n’est en pratique qu’une illusion puisque le processeur ne peut qu’exécuter qu’une séquence d’instructions à la fois.

Pour donner cette illusion, un système d’exploitation multitâche tel que Unix exécute régulièrement des changements de contexte entre threads. Le contexte d’un thread est composé de l’ensemble des contenus des registres qui sont nécessaires à son exécution (y compris le contenu des registres spéciaux tels que %esp, %eip ou %eflags). Ces registres définissent l’état du thread du point de vue du processeur. Pour passer de l’exécution du thread T1 à l’exécution du thread T2, le système d’exploitation doit initier un changement de contexte. Pour réaliser ce changement de contexte, le système d’exploitation initie le transfert du contenu des registres utilisés par le thread T1 vers une zone mémoire lui appartenant. Il transfère ensuite depuis une autre zone mémoire lui appartenant le contexte du thread T2. Si ce changement de contexte est effectué fréquemment, il peut donner l’illusion à l’utilisateur que plusieurs threads ou programmes s’exécutent simultanément.

Sur un système Unix, il y a deux types d’événements qui peuvent provoquer un changement de contexte.

1. Le hardware génère une interruption
2. Un thread exécute un appel système bloquant

Ces deux types d’événements sont fréquents et il est important de bien comprendre comment ils sont traités par le système d’exploitation.

Une interruption est un signal électronique qui est généré par un dispositif connecté au microprocesseur. De nombreux dispositifs d’entrées-sorties comme les cartes réseau ou les contrôleurs de disque peuvent générer une interruption lorsqu’une information a été lue ou reçue et doit être traitée par le processeur. En outre, chaque ordinateur dispose d’une horloge temps réel qui génère des interruptions à une fréquence déterminée par le système d’exploitation mais qui est généralement comprise entre quelques dizaines et quelques milliers de Hz. Ces interruptions nécessitent un traitement rapide de la part du système d’exploitation. Pour cela, le processeur vérifie, à la fin de l’exécution de chaque instruction si un signal d’interruption [3] est présent. Si c’est le cas, le processeur passe automatiquement en mode protégé et positionne le compteur de programme vers une routine de traitement d’interruption, faisant partie du kernel. Cette routine sauvegarde tout d’abord en mémoire le contexte du thread en cours d’exécution. Ensuite, elle analyse l’interruption présente et lance les fonctions du système d’exploitation nécessaires à son traitement.

Le deuxième type d’événement est l’exécution d’un appel système bloquant. Un thread exécute un appel système chaque fois qu’il doit interagir avec le système d’exploitation. Ces appels peuvent être exécutés directement ou via une fonction de la librairie [4]. Il existe deux types d’appels systèmes : les appels bloquants et les appels non-bloquants. Un appel système non-bloquant est un appel système que le système d’exploitation peut exécuter immédiatement. Cet appel retourne généralement une valeur qui fait partie des données du système d’exploitation lui-même. L’appel gettimeofday(2) qui permet de récupérer l’heure actuelle est un exemple d’appel non-bloquant. Un appel système bloquant est un appel système dont le résultat ne peut pas toujours être fourni immédiatement. Les lectures d’information en provenance de l’entrée standard (et donc généralement du clavier) sont un bon exemple simple d’appel système bloquant. Considérons un thread qui exécute la fonction de la librairie getchar(3) qui retourne un caractère lu sur stdin. Cette fonction utilise l’appel système read(2) pour lire un caractère sur stdin. Bien entendu, le système d’exploitation est obligé d’attendre que l’utilisateur presse une touche sur le clavier pour pouvoir fournir le résultat de cet appel système à l’utilisateur. Pendant tout le temps qui s’écoule entre l’exécution de getchar(3) et la pression d’une touche sur le clavier, le thread est bloqué par le système d’exploitation. Plus aucune instruction du thread n’est exécutée tant que la fonction getchar(3) ne s’est pas terminée et le contexte du thread est mis en attente dans une zone mémoire gérée par le système d’exploitation. Il sera redémarré automatiquement par le système d’exploitation lorsque la donnée attendue sera disponible.

Ces interactions entre les threads et le système d’exploitation sont importantes. Pour bien les comprendre, il est utile de noter qu’un thread peut se trouver dans trois états différents du point de vue de son interaction avec le système d’exploitation. Ces trois états sont illustrés dans la figure ci-dessous.

Etats d’un thread d’exécution

Lorsqu’un thread est créé avec la fonction pthread_create(3), il est placé dans l’état Ready. Dans cet état, les instructions du thread ne s’exécutent sur aucun processeur mais il est prêt à être exécuté dès qu’un processeur se libérera. Le deuxième état pour un thread est l’état Running. Dans cet état, le thread est exécuté sur un des processeurs du système. Le dernier état est l’état Blocked. Un thread est dans l’état Blocked lorsqu’il a exécuté un appel système bloquant et que le système d’exploitation attend l’information permettant de retourner le résultat de l’appel système. Pendant ce temps, les instructions du thread ne s’exécutent sur aucun processeur.

Les transitions entre les différents états d’un thread sont gérées par le système d’exploitation. Lorsque plusieurs threads d’exécution sont simultanément actifs, le système d’exploitation doit arbitrer les demandes d’utilisation du CPU de chaque thread. Cet arbitrage est réalisé par l’ordonnanceur (ou scheduler en anglais). Le scheduler est un ensemble d’algorithmes qui sont utilisés par le système d’exploitation pour sélectionner le ou les threads qui peuvent utiliser un processeur à un moment donné. Il y a souvent plus de threads qui sont dans l’état Ready que de processeurs disponibles et le scheduler doit déterminer quels sont les threads à exécuter. Il suffit, dans le contexte de ce chapitre, de considérer que le scheduler choisit un thread à exécuter; il s’agit d’un mécanisme. Le choix lui-même est une politique de scheduling, qui est séparée du mécanisme lui-même gérant l’état des processus. Une politique possible (bien que peu efficace) serait de choisir le thread à exécuter de manière aléatoire parmi les threads en état Ready. Nous verrons des politiques plus intelligentes et efficaces plus tard, dans le chapitre consacré spécifiquement au scheduling.

Il est utile d’analyser en détails quels sont les événements qui peuvent provoquer des transitions entre les états d’un thread. Certains de ces événements sont provoqués par le thread lui-même. C’est le cas de la transition entre l’état Running et l’état Blocked. Elle se produit lorsque le thread exécute un appel système bloquant. Dans ce cas, un processeur redevient disponible et le scheduler peut sélectionner un autre thread pour s’exécuter sur ce processeur. La transition entre l’état Blocked et l’état Running dépend elle du système d’exploitation, directement lorsque le thread a été bloqué par le système d’exploitation ou indirectement lorsque le système d’exploitation attend une information venant d’un dispositif d’entrées-sorties. Les transitions entre les états Running et Ready dépendent elles entièrement du système d’exploitation. Elles se produisent lors de l’exécution du scheduler. Celui-ci est exécuté lorsque certaines interruptions surviennent. Il est exécuté à chaque interruption d’horloge. Cela permet de garantir l’exécution régulière du scheduler même si les seuls threads actifs exécutent une boucle infinie telle que while(true);. A l’occasion de cette interruption, le scheduler mesure le temps d’exécution de chaque thread et si un thread a consommé beaucoup de temps CPU alors que d’autres threads sont dans l’état Ready, le scheduler forcera un changement de contexte pour permettre à un autre thread de s’exécuter. De la même façon, une interruption relative à un dispositif d’entrées-sorties peut faire transiter un thread de l’état Blocked à l’état Ready. Cette modification du nombre de threads dans l’état Ready peut amener le scheduler à devoir effectuer un changement de contexte pour permettre à ce thread de poursuivre son exécution.

Sur une machine monoprocesseur, tous les threads s’exécutent sur le même processeur. Une violation de section critique peut se produire lorsque le scheduler décide de réaliser un changement de contexte alors qu’un thread se trouve dans sa section critique. Si la section critique d’un thread ne contient ni d’appel système bloquant ni d’appel à pthread_yield(3), ce changement de contexte ne pourra se produire que si une interruption survient. Une solution pour résoudre le problème de l’exclusion mutuelle sur un ordinateur monoprocesseur pourrait donc être la suivante :

disable_interrupts();
// début section critique
// ...
// fin section critique
enable_interrupts();

Cette solution est possible, mais elle souffre de plusieurs inconvénients majeurs. Tout d’abord, une désactivation des interruptions perturbe le fonctionnement du système puisque sans interruptions, la plupart des opérations d’entrées-sorties et l’horloge sont inutilisables. Une telle désactivation ne peut être que très courte, par exemple pour modifier une ou quelques variables en mémoire. Ensuite, la désactivation des interruptions, comme d’autres opérations relatives au fonctionnement du matériel, est une opération privilégiée sur un microprocesseur. Elle ne peut être réalisée que par le système d’exploitation. Il faudrait donc imaginer un appel système qui permettrait à un thread de demander au système d’exploitation de désactiver les interruptions. Si un tel appel système existait, le premier programme qui exécuterait disable_interrupts(); sans le faire suivre de enable_interrupts(); quelques instants après pourrait rendre la machine complètement inutilisable puisque sans interruption plus aucune opération d’entrée-sortie n’est possible et qu’en plus le scheduler ne peut plus être activé par l’interruption d’horloge. Pour toutes ces raisons, la désactivation des interruptions n’est pas un mécanisme utilisable par les threads pour résoudre le problème de l’exclusion mutuelle [5].

Coordination par Mutex¶

Le premier mécanisme de coordination entre threads dans la librairie POSIX sont les mutex. Un mutex (abréviation de mutual exclusion) est une structure de données qui permet de contrôler l’accès à une ressource. Un mutex qui contrôle une ressource peut se trouver dans deux états :

• libre (ou unlocked en anglais). Cet état indique que la ressource est libre et peut être utilisée sans risquer de provoquer une violation d’exclusion mutuelle.
• réservée (ou locked en anglais). Cet état indique que la ressource associée est actuellement utilisée et qu’elle ne peut pas être utilisée par un autre thread.

Un mutex est toujours associé à une ressource. Cette ressource peut être une variable globale comme dans les exemples précédents, mais cela peut aussi être une structure de données plus complexe, une base de données, un fichier, ... Un mutex s’utilise par l’intermédiaire de deux fonctions de base. La fonction lock permet à un thread d’acquérir l’usage exclusif d’une ressource. Si la ressource est libre, elle est marquée comme réservée et le thread y accède directement. Si la ressource est occupée, le thread est bloqué par le système d’exploitation jusqu’à ce qu’elle ne devienne libre. A ce moment, le thread pourra poursuivre son exécution et utilisera la ressource avec la certitude qu’aucun autre thread ne pourra faire de même. Lorsque le thread a terminé d’utiliser la ressource associée au mutex, il appelle la fonction unlock. Cette fonction vérifie d’abord si un ou plusieurs autres threads sont en attente pour cette ressource (c’est-à-dire qu’ils ont appelé la fonction lock mais celle-ci n’a pas encore réussi). Si c’est le cas, un (et un seul) thread est choisi parmi les threads en attente et celui-ci accède à la ressource. Il est important de noter qu’un programme ne peut faire aucune hypothèse sur l’ordre dans lequel les threads qui sont en attente sur un mutex pourront accéder à la ressource partagée. Le programme doit être conçu en faisant l’hypothèse que si plusieurs threads sont bloqués sur un appel à lock pour un mutex, le thread qui sera libéré est choisi aléatoirement.

Sans entrer dans des détails de mise en œuvre qui dépassent le contexte de ce cours, on peut schématiquement représenter un mutex comme étant une structure de données qui contient deux informations :

• la valeur actuelle du mutex ( locked ou unlocked)
• une queue contenant l’ensemble des threads qui sont bloqués en attente du mutex

Schématiquement, l’implémentation des fonctions lock et unlock peut être représentée par le code ci-dessous.

lock(mutex m) {
 if(m.val==unlocked)
 {
   m.val=locked;
 }
 else
 {
   // Place this thread in m.queue;
   // This thread is blocked;
 }
}

Le fonction lock vérifie si le mutex est libre. Dans ce cas, le mutex est marqué comme réservé et la fonction lock réussi. Sinon, le thread qui a appelé la fonction lock est placé dans la queue associée au mutex et passe dans l’état Blocked jusqu’à ce qu’un autre thread ne libère le mutex.

unlock(mutex m) {
 if(m.queue is empty)
 {
   m.val=unlocked;
 }
 else
 {
  // Remove one thread(T) from m.queue;
  // Mark Thread(T) as ready to run;
 }
}

La fonction unlock vérifie d’abord l’état de la queue associée au mutex. Si la queue est vide, cela indique qu’aucun thread n’est en attente. Dans ce cas, la valeur du mutex est mise à unlocked et la fonction se termine. Sinon, un des threads en attente dans la queue associée au mutex est choisi et marqué comme prêt à s’exécuter. Cela indique implicitement que l’appel à lock fait par ce thread réussi et qu’il peut accéder à la ressource.

Le code présenté ci-dessus n’est qu’une illustration du fonctionnement des opérations lock et unlock. Pour que ces opérations fonctionnent correctement, il faut bien entendu que les modifications aux valeurs du mutex et à la queue qui y est associée se fassent en garantissant qu’un seul thread exécute l’une de ces opérations sur un mutex à un instant donné. Nous verrons dans le détail comment garantir cela en utilisant des instructions spécifiques (dites atomiques) du jeu d’instruction, dans un prochain chapitre.

Les mutex sont fréquemment utilisés pour protéger l’accès à une zone de mémoire partagée. Ainsi, si la variable globale g est utilisée en écriture et en lecture par deux threads, celle-ci devra être protégée par un mutex. Toute modification de cette variable devra être entourée par des appels à lock et unlock.

En C, cela se fait en utilisant les fonctions pthread_mutex_lock(3posix) et pthread_mutex_unlock(3posix). Un mutex POSIX est représenté par une structure de données de type pthread_mutex_t qui est définie dans le fichier pthread.h. Avant d’être utilisé, un mutex doit être initialisé via la fonction pthread_mutex_init(3posix) et lorsqu’il n’est plus nécessaire, les ressources qui lui sont associées doivent être libérées avec la fonction pthread_mutex_destroy(3posix).

L’exemple ci-dessous reprend le programme dans lequel une variable globale est incrémentée par plusieurs threads.

#include <pthread.h>
#define NTHREADS 4

long global=0;
pthread_mutex_t mutex_global;

int increment(int i) {
  return i+1;
}

void *func(void * param) {
  int err;
  for(int j=0;j<1000000;j++) {
    err=pthread_mutex_lock(&mutex_global);
    if(err!=0)
      error(err,"pthread_mutex_lock");
    global=increment(global);
    err=pthread_mutex_unlock(&mutex_global);
    if(err!=0)
      error(err,"pthread_mutex_unlock");
  }
  return(NULL);
}

int main (int argc, char *argv[])  {
  pthread_t thread[NTHREADS];
  int err;

  err=pthread_mutex_init( &mutex_global, NULL);
  if(err!=0)
      error(err,"pthread_mutex_init");

  for(int i=0;i<NTHREADS;i++) {
    err=pthread_create(&(thread[i]),NULL,&func,NULL);
    if(err!=0)
      error(err,"pthread_create");
  }
  for(int i=0; i<1000000000;i++) { /*...*/ }

  for(int i=NTHREADS-1;i>=0;i--) {
    err=pthread_join(thread[i],NULL);
    if(err!=0)
      error(err,"pthread_join");
  }

  err=pthread_mutex_destroy(&mutex_global);
  if(err!=0)
    error(err,"pthread_mutex_destroy");

  printf("global: %ld\n",global);

  return(EXIT_SUCCESS);
}

Il est utile de regarder un peu plus en détails les différentes fonctions utilisées par ce programme. Tout d’abord, la ressource partagée est ici la variable global. Dans l’ensemble du programme, l’accès à cette variable est protégé par le mutex mutex_global. Celui-ci est représenté par une structure de données de type pthread_mutex_t.

Avant de pouvoir utiliser un mutex, il est nécessaire de l’initialiser. Cette initialisation est effectuée par la fonction pthread_mutex_init(3posix) qui prend deux arguments [6]. Le premier est un pointeur vers une structure pthread_mutex_t et le second un pointeur vers une structure pthread_mutexattr_t contenant les attributs de ce mutex. Tout comme lors de la création d’un thread, ces attributs permettent de spécifier des paramètres à la création du mutex. Ces attributs peuvent être manipulés en utilisant les fonctions pthread_mutexattr_gettype(3posix) et pthread_mutexattr_settype(3posix). Dans le cadre de ces notes, nous utiliserons exclusivement les attributs par défaut et créerons toujours un mutex en passant NULL comme second argument à la fonction pthread_mutex_init(3posix).

Lorsqu’un mutex POSIX est initialisé, la ressource qui lui est associée est considérée comme libre. L’accès à la ressource doit se faire en précédant tout accès à la ressource par un appel à la fonction pthread_mutex_lock(3posix). En fonction des attributs spécifiés à la création du mutex, il peut y avoir de très rares cas où la fonction retourne une valeur non nulle. Dans ce cas, le type d’erreur est indiqué via errno. Lorsque le thread n’a plus besoin de la ressource protégée par le mutex, il doit appeler la fonction pthread_mutex_unlock(3posix) pour libérer la ressource protégée.

pthread_mutex_lock(3posix) et pthread_mutex_unlock(3posix) sont toujours utilisés en couple. pthread_mutex_lock(3posix) doit toujours précéder l’accès à la ressource partagée et pthread_mutex_unlock(3posix) doit être appelé dès que l’accès exclusif à la ressource partagée n’est plus nécessaire.

L’utilisation des mutex permet de résoudre correctement le problème de l’exclusion mutuelle. Pour s’en convaincre, considérons le programme ci-dessus et les threads qui exécutent la fonction func. Celle-ci peut être résumée par les trois lignes suivantes :

pthread_mutex_lock(&mutex_global);
global=increment(global);
pthread_mutex_unlock(&mutex_global);

Pour montrer que cette solution répond bien au problème de l’exclusion mutuelle, il faut montrer qu’elle respecte la propriété de sûreté et la propriété de vivacité. Pour la propriété de sûreté, c’est par construction des mutex et parce que chaque thread exécute pthread_mutex_lock(3posix) avant d’entrer en section critique et pthread_mutex_unlock(3posix) dès qu’il en sort. Considérons le cas de deux threads qui sont en concurrence pour accéder à cette section critique. Le premier exécute pthread_mutex_lock(3posix). Il accède à sa section critique. A partir de cet instant, le second thread sera bloqué dès qu’il exécute l’appel à pthread_mutex_lock(3posix). Il restera bloqué dans l’exécution de cette fonction jusqu’à ce que le premier thread sorte de sa section critique et exécute pthread_mutex_unlock(3posix). A ce moment, le premier thread n’est plus dans sa section critique et le système peut laisser le second y entrer en terminant l’exécution de l’appel à pthread_mutex_lock(3posix). Si un troisième thread essaye à ce moment d’entrer dans la section critique, il sera bloqué sur son appel à pthread_mutex_lock(3posix).

Pour montrer que la propriété de vivacité est bien respectée, il faut montrer qu’un thread ne sera pas empêché éternellement d’entrer dans sa section critique. Un thread peut être empêché d’entrer dans sa section critique en étant bloqué sur l’appel à pthread_mutex_lock(3posix). Comme chaque thread exécute pthread_mutex_unlock(3posix) dès qu’il sort de sa section critique, le thread en attente finira par être exécuté. Pour qu’un thread utilisant le code ci-dessus ne puisse jamais entrer en section critique, il faudrait qu’il y aie en permanence plusieurs threads en attente sur pthread_mutex_unlock(3posix) et que notre thread ne soit jamais sélectionné par le système lorsque le thread précédent termine sa section critique.