Linux Certif

Toute la documentation sur la certification Linux LPI

Rechercher une page de manuel

pthreads

NOM

pthreads - Threads POSIX

DESCRIPTION

POSIX.1 décrit une série d'interfaces (fonctions et fichiers d'en-têtes) pour la programmation threadée, couramment appelée threads POSIX, ou pthreads. Un unique processus peut contenir plusieurs threads, qui exécutent tous le même programme. Ces threads partagent la même mémoire globale (segments de données et tas), mais chaque thread a sa propre pile (variables automatiques).

POSIX.1 requiert aussi que les threads partagent une série d'autres attributs (ces attributs sont par processus, plutôt que par thread) :

-

identifiant de processus (PID)

-

identifiant de processus père (PPID)

-

identifiant de groupe de processus (PGID) et identifiant de session (SID)

-

terminal de contrôle

-

identifiants d'utilisateur et de groupe

-

descripteurs de fichiers ouverts

-

verrouillages d'enregistrements (voir fcntl(2))

-

gestion de signaux

-

masque de création de fichier (umask(2))

-

répertoire de travail (chdir(2)) et répertoire racine (chroot(2))

-

temporisations d'intervalle (setitimer(2)) et temporisations POSIX (timer_create())

-

valeur de politesse (setpriority(2))

-

limites de ressources (setrlimit(2))

-

mesures de consommation de temps CPU (times(2)) et de ressources (getrusage(2))

En plus de la pile, POSIX.1 indique que plusieurs autres attributs sont distincts pour chaque thread, dont les suivants :

-

identifiant de thread (le type de donnée pthread_t)

-

masque de signaux (pthread_sigmask())

-

la variable errno

-

pile spécifique de signal (sigaltstack(2))

-

politique et priorité d'ordonnancement temps réel (sched_setscheduler(2) et sched_setparam(2))

Les caractéristiques spécifiques Linux suivantes sont également distinctes pour chaque thread :

-

capacités (voir capabilities(7))

-

affinité CPU (sched_setaffinity(2))

Compiler sous Linux

Sous Linux, les programmes utilisant l'API pthreads doivent être compilés avec cc -pthread.

Implémentations des threads POSIX sous Linux

Deux implémentations différentes des threads ont été fournies par la bibliothèque C de GNU sous Linux :

-

LinuxThreads est l'implémentation des pthreads originelle (mais aujourd'hui obsolète)

-

NPTL (Native POSIX Threads Library) est l'implémentation moderne des pthreads. Par rapport à LinuxThreads, NPTL se conforme mieux aux obligations de la norme POSIX.1, et une meilleure performance lors de la création d'un grand nombre de threads. NPTL nécessite des fonctionnalités présentes dans Linux 2.6.

Ces deux implémentations sont de type 1:1, ce qui veut dire que chaque thread correspond à une entité d'ordonnancement du noyau.

Les deux implémentations utilisent l'appel système clone(2) de Linux. Dans NPTL, les primitives de synchronisation de threads (mutexes, jonction de thread, etc.) sont implémentées avec l'appel système futex(2) de Linux.

Les bibliothèques GNU C récentes fournissent à la fois LinuxThreads et NPTL, et utilisent NPTL par défaut si le noyau utilisé le permet.

LinuxThreads

Les fonctionnalités importantes de cette implémentation sont les suivantes :

-

En plus du thread principal (initial) et des threads créés par le programme avec pthread_create(), l'implémentation crée un thread de gestion. Ce thread s'occupe de la création et de la terminaison des threads. (Des problèmes peuvent survenir si ce thread est tué de façon imprévue.)

-

Les signaux sont utilisés en interne par l'implémentation. Sous Linux 2.2 et suivants, les trois premiers signaux temps-réel sont utilisés. Sous les noyaux plus anciens, LinuxThreads utilise SIGUSR1 et SIGUSR2. Les applications doivent éviter d'utiliser les signaux utilisés par l'implémentation.

-

Les threads ne partagent pas leur identifiant de processus. (En fait, les threads LinuxThreads sont implémentés comme des processus partageant plus d'informations qu'à l'habitude, mais pas leur identifiant de processus.) Les threads LinuxThreads (y compris le thread de gestion) sont visibles comme des processus différents avec ps(1).

L'implémentation LinuxThreads s'écarte de la spécification POSIX.1 par plusieurs aspects, dont les suivants :

-

Les appels à getpid(2) renvoient une valeur distincte dans chaque thread.

-

Les appels à getppid(2) dans les threads autres que le thread principal renvoient l'identifiant de processus du thread de gestion ; getppid(2) dans ces threads devrait renvoyer la même valeur que dans le thread principal.

-

Lorsqu'un thread crée un nouveau processus fils avec fork(2), n'importe quel thread devrait pouvoir utiliser wait(2) pour attendre la terminaison de ce fils. Cependant, l'implémentation ne permet qu'au thread ayant créé le fils d'appeler wait(2) pour l'attendre.

-

Lorsqu'un thread appelle execve(2), tous les autres threads sont terminés (comme le prescrit POSIX.1). Cependant, le processus résultant a le même PID que le thread ayant appelé execve(2) : il devrait avoir le même PID que le thread principal.

-

Les threads ne partagent pas leurs identifiants d'utilisateur et de groupe. Ceci peut causer des complications pour les programmes setuid et provoquer des erreurs dans les fonctions pthreads si une application change d'identifiant avec seteuid(2) et consorts.

-

Les threads ne partagent pas l'identifiant de session et de groupe de processus.

-

Les threads ne partagent pas les verrouillages d'enregistrements créés avec fcntl(2).

-

L'information renvoyée par times(2) et getrusage(2) est par thread au lieu d'être par processus.

-

Les threads ne partagent pas les valeurs « undo » de sémaphores (voir semop(2)).

-

Les threads ne partagent pas les temporisations d'intervalles.

-

Les threads ne partagent pas leur valeur de politesse.

-

POSIX.1 distingue les notions de signal envoyé au processus dans son ensemble, et de signal envoyé à un thread individuellement. Selon POSIX.1, un signal envoyé au processus (par exemple avec kill(2)) sera géré par un thread choisi arbitrairement au sein du processus. LinuxThreads ne permet pas d'envoyer un signal au processus, mais seulement à un thread spécifique.

-

Les threads ont des paramètres de pile spécifique de signal distincts. Cependant, les paramètres de pile spécifique d'un nouveau thread sont copiés à partir du thread qui l'a créé, ce qui veut dire que les threads partagent initialement une même pile spécifique de signaux. (Un nouveau thread devrait démarrer sans pile spécifique de signaux. Si deux threads gèrent un signal sur leur pile spécifique au même moment, des échecs imprévisibles du programme risquent de se produire.)

NPTL

Avec NPTL, tous les threads d'un processus sont placés dans le même groupe de threads. Tous les membres d'un groupe de threads partagent le même PID. NPTL n'utilise pas de thread de gestion. NPTL utilise en interne les deux premiers signaux temps-réel ; ces signaux ne peuvent pas être utilisés dans les applications.

NPTL a encore quelques non conformités à POSIX.1 :

-

Les threads ne partagent pas leur valeur de politesse.

Certaines non conformités n'apparaissent qu'avec des noyaux plus anciens :

-

L'information renvoyée par times(2) et getrusage(2) est par thread au lieu d'être globale au processus (corrigé dans le noyau 2.6.9).

-

Les threads ne partagent pas les limites de ressources (corrigé dans le noyau 2.6.10).

-

Les threads ne partagent pas les temporisations d'intervalles (corrigé dans le noyau 2.6.12).

-

Seul le thread principal est autorisé à démarrer une nouvelle session avec setsid(2) (corrigé dans le noyau 2.6.16).

-

Seul le thread principal est autorisé à rendre le processus leader de son groupe de processus avec setpgid(2) (corrigé dans le noyau 2.6.16).

-

Les threads ont des paramètres de pile spécifique de signaux distincts. Cependant, les paramètres de pile spécifique d'un nouveau thread sont copiés sur ceux du thread qui l'a créé, et les threads partagent donc initialement leur pile spécifique de signaux (corrigé dans le noyau 2.6.16).

Veuillez noter les points suivants à propos de l'implémentation NPTL :

-

Si la limite souple de taille de pile (voir dans setrlimit(2) la description de RLIMIT_STACK) est différente de unlimited, cette valeur détermine la taille de pile par défaut pour les nouveaux threads. Pour avoir un effet, cette limite doit être fixée avant le démarrage du programme, par exemple en utilisant la commande ulimit -s du shell (limit stacksize dans csh).

Déterminer l'implémentation des threads utilisée

Depuis glibc 2.3.2, la commande getconf(1) peut être utilisée pour déterminer l'implémentation de threads par défaut du système, par exemple :

 
 bash$ getconf GNU_LIBPTHREAD_VERSION
 NPTL 2.3.4
 

Avec des versions plus anciennes de la glibc, une commande comme la suivante devrait être suffisante pour déterminer l'implémentation de threads par défaut :

 
 bash$ $( ldd /bin/ls | grep libc.so | awk '{print $3}' ) | \
                 egrep -i 'threads|ntpl'
         Native POSIX Threads Library by Ulrich Drepper et al
 

Choisir l'implémentation des threads : LD_ASSUME_KERNEL

Sur les systèmes avec une glibc fournissant à la fois LinuxThreads et NPTL, la variable d'environnement LD_ASSUME_KERNEL peut être utilisée pour écraser le choix par défaut d'implémentation de threads fait par l'éditeur de liens dynamique. Cette variable indique à l'éditeur de liens dynamique qu'il doit faire comme s'il était exécuté avec une version particulière du noyau. En indiquant une version du noyau ne fournissant pas les fonctionnalités nécessitées par NPTL, on peut forcer l'utilisation de LinuxThreads. (La raison la plus probable pour cela est d'exécuter une application (boguée) qui dépend d'un comportement de LinuxThreads non conforme à la spécification.) Par exemple :

 
 bash$ $( LD_ASSUME_KERNEL=2.2.5 ldd /bin/ls | grep libc.so | \
                 awk '{print $3}' ) | egrep -i 'threads|ntpl'
         linuxthreads-0.10 by Xavier Leroy
 

VOIR AUSSI

clone(2), futex(2), gettid(2), futex(7) et diverses pages de manuel Pthreads, par exemple : pthread_atfork(3), pthread_cleanup_push(3), pthread_cond_signal(3), pthread_cond_wait(3), pthread_create(3), pthread_detach(3), pthread_equal(3), pthread_exit(3), pthread_key_create(3), pthread_kill(3), pthread_mutex_lock(3), pthread_mutex_unlock(3), pthread_once(3), pthread_setcancelstate(3), pthread_setcanceltype(3), pthread_setspecific(3), pthread_sigmask(3) et pthread_testcancel(3).

TRADUCTION

Cette page de manuel a été traduite et mise à jour par Christophe Blaess <http://www.blaess.fr/christophe/> entre 1996 et 2003, puis par Alain Portal <aportal AT univ-montp2 DOT fr> jusqu'en 2006, et mise à disposition sur http://manpagesfr.free.fr/.

Les mises à jour et corrections de la version présente dans Debian sont directement gérées par Julien Cristau <jcristau@debian.org> et l'équipe francophone de traduction de Debian.

Veuillez signaler toute erreur de traduction en écrivant à <debian-l10n-french@lists.debian.org> ou par un rapport de bogue sur le paquet manpages-fr.

Vous pouvez toujours avoir accès à la version anglaise de ce document en utilisant la commande « man -L C <section> <page_de_man> ».