Provided by:
manpages-fr_3.27fr1.4-1_all 
NOM
pthreads - Threads POSIX
DESCRIPTION
POSIX.1 decrit une serie d'interfaces (fonctions et fichiers d'en-
tetes) pour la programmation multithread, couramment appelee threads
POSIX, ou pthreads. Un unique processus peut contenir plusieurs
threads, qui executent tous le meme programme. Ces threads partagent la
meme memoire globale (segments de donnees et tas), mais chaque thread a
sa propre pile (variables automatiques).
POSIX.1 requiert aussi que les threads partagent une serie d'autres
attributs (ces attributs sont par processus, plutot que par thread) :
- identifiant de processus (PID)
- identifiant de processus pere (PPID)
- identifiant de groupe de processus (PGID) et identifiant de session
(SID)
- terminal de controle
- identifiants d'utilisateur et de groupe
- descripteurs de fichier ouverts
- verrouillages d'enregistrements (consultez fcntl(2))
- gestion de signaux
- masque de creation de fichier (umask(2))
- repertoire de travail (chdir(2)) et repertoire racine (chroot(2))
- temporisations d'intervalle (setitimer(2)) et temporisations POSIX
(timer_create(2))
- 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 donnee pthread_t)
- masque de signaux (pthread_sigmask(3))
- la variable errno
- pile specifique de signal (sigaltstack(2))
- politique et priorite d'ordonnancement temps-reel
(sched_setscheduler(2) et sched_setparam(2))
Les caracteristiques specifiques a Linux suivantes sont egalement
distinctes pour chaque thread :
- capacites (consultez capabilities(7))
- affinite CPU (sched_setaffinity(2))
Valeurs de retour des fonctions pthreads
La plupart des fonctions pthreads renvoient 0 en cas de succes et un
numero d'erreur en cas d'echec. Notez que les fonctions pthreads ne
positionnent pas errno. Pour chacune des fonctions pthreads qui peuvent
produire une erreur, POSIX.1-2001 specifie que la fonction ne peut pas
echouer avec l'erreur EINTR.
Identifiants de thread
Chacun des threads d'un processus a un unique identifiant de thread
(stocke dans le type pthread_t). Cet identifiant est renvoye a
l'appelant de pthread_create(3) et un thread peut obtenir son propre
identifiant de thread en utilisant pthread_self(3). Les identifiants de
thread n'ont la garantie d'etre uniques qu'a l'interieur d'un
processus. Un identifiant de thread peut etre reutilise apres qu'un
thread qui s'est termine a ete rejoint ou qu'un thread detache se soit
termine. Pour toutes les fonctions qui acceptent un identifiant de
thread en parametre, cet identifiant de thread se refere par definition
a un thread du meme processus que l'appelant.
Fonctions s^ures du point de vue des threads
Une fonction sure du point de vue des threads est une fonction qui peut
etre appelee en toute surete (c'est-a-dire qu'elle renverra le meme
resultat d'ou qu'elle soit appelee) par plusieurs threads en meme
temps.
POSIX.1-2001 et POSIX.1-2008 exigent que toutes les fonctions indiquees
dans la norme soient sures du point de vue des threads, excepte les
fonctions suivantes :
asctime()
basename()
catgets()
crypt()
ctermid() avec un parametre non NULL
ctime()
dbm_clearerr()
dbm_close()
dbm_delete()
dbm_error()
dbm_fetch()
dbm_firstkey()
dbm_nextkey()
dbm_open()
dbm_store()
dirname()
dlerror()
drand48()
ecvt() [POSIX.1-2001 uniquement (fonction supprimee dans POSIX.1-2008)]
encrypt()
endgrent()
endpwent()
endutxent()
fcvt() [POSIX.1-2001 uniquement (fonction supprimee dans POSIX.1-2008)]
ftw()
gcvt() [POSIX.1-2001 uniquement (fonction supprimee dans POSIX.1-2008)]
getc_unlocked()
getchar_unlocked()
getdate()
getenv()
getgrent()
getgrgid()
getgrnam()
gethostbyaddr() [POSIX.1-2001 uniquement (fonction supprimee dans POSIX.1-2008)]
gethostbyname() [POSIX.1-2001 uniquement (fonction supprimee dans POSIX.1-2008)]
gethostent()
getlogin()
getnetbyaddr()
getnetbyname()
getnetent()
getopt()
getprotobyname()
getprotobynumber()
getprotoent()
getpwent()
getpwnam()
getpwuid()
getservbyname()
getservbyport()
getservent()
getutxent()
getutxid()
getutxline()
gmtime()
hcreate()
hdestroy()
hsearch()
inet_ntoa()
l64a()
lgamma()
lgammaf()
lgammal()
localeconv()
localtime()
lrand48()
mrand48()
nftw()
nl_langinfo()
ptsname()
putc_unlocked()
putchar_unlocked()
putenv()
pututxline()
rand()
readdir()
setenv()
setgrent()
setkey()
setpwent()
setutxent()
strerror()
strsignal() [Ajoutee dans POSIX.1-2008]
strtok()
system() [Ajoutee dans POSIX.1-2008]
tmpnam() avec un parametre non NULL
ttyname()
unsetenv()
wcrtomb() si son dernier parametre est NULL
wcsrtombs() si son dernier parametre est NULL
wcstombs()
wctomb()
Points d'annulation
POSIX.1 specifie que certaines fonctions doivent, et certaines autres
fonctions peuvent, etre des points d'annulation. Si un thread est
annulable, que son type d'annulation est retarde (<< deferred >>) et
qu'une demande d'annulation est en cours pour ce thread, alors le
thread est annule quand il appelle une fonction qui est un point
d'annulation.
POSIX.1-2001 et/ou POSIX.1-2008 exigent que les fonctions suivantes
soient des points d'annulation :
accept()
aio_suspend()
clock_nanosleep()
close()
connect()
creat()
fcntl() F_SETLKW
fdatasync()
fsync()
getmsg()
getpmsg()
lockf() F_LOCK
mq_receive()
mq_send()
mq_timedreceive()
mq_timedsend()
msgrcv()
msgsnd()
msync()
nanosleep()
open()
openat() [Ajoutee dans POSIX.1-2008]
pause()
poll()
pread()
pselect()
pthread_cond_timedwait()
pthread_cond_wait()
pthread_join()
pthread_testcancel()
putmsg()
putpmsg()
pwrite()
read()
readv()
recv()
recvfrom()
recvmsg()
select()
sem_timedwait()
sem_wait()
send()
sendmsg()
sendto()
sigpause() [POSIX.1-2001 uniquement (dans la liste des fonctions pouvant etre un point d'annulation dans POSIX.1-2008)]
sigsuspend()
sigtimedwait()
sigwait()
sigwaitinfo()
sleep()
system()
tcdrain()
usleep() [POSIX.1-2001 uniquement (fonction supprimee dans POSIX.1-2008)]
wait()
waitid()
waitpid()
write()
writev()
POSIX.1-2001 et/ou POSIX.1-2008 indiquent que les fonctions suivantes
peuvent etre des points d'annulation :
access()
asctime()
asctime_r()
catclose()
catgets()
catopen()
chmod() [Added in POSIX.1-2008]
chown() [Added in POSIX.1-2008]
closedir()
closelog()
ctermid()
ctime()
ctime_r()
dbm_close()
dbm_delete()
dbm_fetch()
dbm_nextkey()
dbm_open()
dbm_store()
dlclose()
dlopen()
dprintf() [Added in POSIX.1-2008]
endgrent()
endhostent()
endnetent()
endprotoent()
endpwent()
endservent()
endutxent()
faccessat() [Added in POSIX.1-2008]
fchmod() [Added in POSIX.1-2008]
fchmodat() [Added in POSIX.1-2008]
fchown() [Added in POSIX.1-2008]
fchownat() [Added in POSIX.1-2008]
fclose()
fcntl() (for any value of cmd argument)
fflush()
fgetc()
fgetpos()
fgets()
fgetwc()
fgetws()
fmtmsg()
fopen()
fpathconf()
fprintf()
fputc()
fputs()
fputwc()
fputws()
fread()
freopen()
fscanf()
fseek()
fseeko()
fsetpos()
fstat()
fstatat() [Added in POSIX.1-2008]
ftell()
ftello()
ftw()
futimens() [Added in POSIX.1-2008]
fwprintf()
fwrite()
fwscanf()
getaddrinfo()
getc()
getc_unlocked()
getchar()
getchar_unlocked()
getcwd()
getdate()
getdelim() [Added in POSIX.1-2008]
getgrent()
getgrgid()
getgrgid_r()
getgrnam()
getgrnam_r()
gethostbyaddr() [SUSv3 only (function removed in POSIX.1-2008)]
gethostbyname() [SUSv3 only (function removed in POSIX.1-2008)]
gethostent()
gethostid()
gethostname()
getline() [Added in POSIX.1-2008]
getlogin()
getlogin_r()
getnameinfo()
getnetbyaddr()
getnetbyname()
getnetent()
getopt() (if opterr is nonzero)
getprotobyname()
getprotobynumber()
getprotoent()
getpwent()
getpwnam()
getpwnam_r()
getpwuid()
getpwuid_r()
gets()
getservbyname()
getservbyport()
getservent()
getutxent()
getutxid()
getutxline()
getwc()
getwchar()
getwd() [SUSv3 only (function removed in POSIX.1-2008)]
glob()
iconv_close()
iconv_open()
ioctl()
link()
linkat() [Added in POSIX.1-2008]
lio_listio() [Added in POSIX.1-2008]
localtime()
localtime_r()
lockf() [Added in POSIX.1-2008]
lseek()
lstat()
mkdir() [Added in POSIX.1-2008]
mkdirat() [Added in POSIX.1-2008]
mkdtemp() [Added in POSIX.1-2008]
mkfifo() [Added in POSIX.1-2008]
mkfifoat() [Added in POSIX.1-2008]
mknod() [Added in POSIX.1-2008]
mknodat() [Added in POSIX.1-2008]
mkstemp()
mktime()
nftw()
opendir()
openlog()
pathconf()
pclose()
perror()
popen()
posix_fadvise()
posix_fallocate()
posix_madvise()
posix_openpt()
posix_spawn()
posix_spawnp()
posix_trace_clear()
posix_trace_close()
posix_trace_create()
posix_trace_create_withlog()
posix_trace_eventtypelist_getnext_id()
posix_trace_eventtypelist_rewind()
posix_trace_flush()
posix_trace_get_attr()
posix_trace_get_filter()
posix_trace_get_status()
posix_trace_getnext_event()
posix_trace_open()
posix_trace_rewind()
posix_trace_set_filter()
posix_trace_shutdown()
posix_trace_timedgetnext_event()
posix_typed_mem_open()
printf()
psiginfo() [Added in POSIX.1-2008]
psignal() [Added in POSIX.1-2008]
pthread_rwlock_rdlock()
pthread_rwlock_timedrdlock()
pthread_rwlock_timedwrlock()
pthread_rwlock_wrlock()
putc()
putc_unlocked()
putchar()
putchar_unlocked()
puts()
pututxline()
putwc()
putwchar()
readdir()
readdir_r()
readlink() [Added in POSIX.1-2008]
readlinkat() [Added in POSIX.1-2008]
remove()
rename()
renameat() [Added in POSIX.1-2008]
rewind()
rewinddir()
scandir() [Added in POSIX.1-2008]
scanf()
seekdir()
semop()
setgrent()
sethostent()
setnetent()
setprotoent()
setpwent()
setservent()
setutxent()
sigpause() [Added in POSIX.1-2008]
stat()
strerror()
strerror_r()
strftime()
symlink()
symlinkat() [Added in POSIX.1-2008]
sync()
syslog()
tmpfile()
tmpnam()
ttyname()
ttyname_r()
tzset()
ungetc()
ungetwc()
unlink()
unlinkat() [Added in POSIX.1-2008]
utime() [Added in POSIX.1-2008]
utimensat() [Added in POSIX.1-2008]
utimes() [Added in POSIX.1-2008]
vdprintf() [Added in POSIX.1-2008]
vfprintf()
vfwprintf()
vprintf()
vwprintf()
wcsftime()
wordexp()
wprintf()
wscanf()
Une implementation peut egalement indiquer d'autres fonctions non
specifiees dans la norme comme etant des points d'annulation. En
particulier, une implementation marquera probablement toute fonction
non standard qui peut bloquer comme etant un point d'annulation (ceci
inclus la plupart des fonctions qui peuvent toucher des fichiers).
Compiler sous Linux
Sous Linux, les programmes utilisant l'API pthreads doivent etre
compiles avec cc -pthread.
Impl'ementations des threads POSIX sous Linux
Deux implementations differentes des threads ont ete fournies par la
bibliotheque C de GNU sous Linux :
LinuxThreads
Il s'agit de l'implementation des Pthreads originelle. Depuis la
glibc 2.4, cette implementation n'est plus prise en charge.
NPTL (Native POSIX Threads Library)
Il s'agit de l'implementation moderne des Pthreads. Par rapport
a LinuxThreads, NPTL se conforme mieux aux exigences de la norme
POSIX.1, et une meilleure performance lors de la creation d'un
grand nombre de threads. NPTL est disponible depuis la
glibc 2.3.2, et necessite des fonctionnalites presentes dans le
noyau Linux 2.6.
Ces deux implementation sont dit de type 1:1, ce qui veut dire que
chaque thread correspond a une entite d'ordonnancement du noyau. Les
deux implementations utilisent l'appel systeme clone(2) de Linux. Dans
NPTL, les primitives de synchronisation de threads (mutexes, jonction
de thread, etc.) sont implementees avec l'appel systeme futex(2) de
Linux.
LinuxThreads
Les fonctionnalites importantes de cette implementation sont les
suivantes :
- En plus du thread principal (initial) et des threads crees par le
programme avec pthread_create(3), l'implementation cree un thread de
gestion. Ce thread s'occupe de la creation et de la terminaison des
threads. Des problemes peuvent survenir si ce thread est tue de
facon imprevue.
- Les signaux sont utilises en interne par l'implementation. Sous
Linux 2.2 et suivants, les trois premiers signaux temps-reel sont
utilises (voir aussi signal(7)). Sous les noyaux plus anciens,
LinuxThreads utilise SIGUSR1 et SIGUSR2. Les applications doivent
eviter d'utiliser les signaux utilises par l'implementation.
- Les threads ne partagent pas leur identifiant de processus. (En
fait, les threads LinuxThreads sont implementes comme des processus
partageant plus d'informations qu'a l'habitude, mais pas leur
identifiant de processus.) Les threads LinuxThreads (y compris le
thread de gestion) sont visibles comme des processus differents avec
ps(1).
L'implementation LinuxThreads s'ecarte de la specification POSIX.1 par
plusieurs aspects, dont les suivants :
- Les appels a getpid(2) renvoient une valeur distincte dans chaque
thread.
- Les appels a 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 meme
valeur que dans le thread principal.
- Lorsqu'un thread cree 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'implementation ne permet
qu'au thread ayant cree le fils d'appeler wait(2) pour l'attendre.
- Lorsqu'un thread appelle execve(2), tous les autres threads sont
termines (comme le prescrit POSIX.1). Cependant, le processus
resultant a le meme PID que le thread ayant appele execve(2) : il
devrait avoir le meme 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
crees avec fcntl(2).
- L'information renvoyee par times(2) et getrusage(2) est par thread
au lieu d'etre par processus.
- Les threads ne partagent pas les valeurs << undo >> de semaphores
(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 envoye au processus dans son
ensemble, et de signal envoye a un thread individuellement. Selon
POSIX.1, un signal envoye au processus (par exemple avec kill(2))
sera gere par un thread choisi arbitrairement au sein du processus.
LinuxThreads ne permet pas d'envoyer un signal au processus, mais
seulement a un thread specifique.
- Les threads ont des parametres de pile specifique de signal
distincts. Cependant, les parametres de pile specifique d'un nouveau
thread sont copies a partir du thread qui l'a cree, ce qui veut dire
que les threads partagent initialement une meme pile specifique de
signaux. (Un nouveau thread devrait demarrer sans pile specifique de
signaux. Si deux threads gerent un signal sur leur pile specifique
au meme moment, des echecs imprevisibles du programme risquent de se
produire.)
NPTL
Avec NPTL, tous les threads d'un processus sont places dans le meme
groupe de threads. Tous les membres d'un groupe de threads partagent le
meme PID. NPTL n'utilise pas de thread de gestion. NPTL utilise en
interne les deux premiers signaux temps-reel (voir aussi signal(7)) ;
ces signaux ne peuvent pas etre utilises dans les applications.
NPTL a encore au moins une non conformite a POSIX.1 :
- Les threads ne partagent pas leur valeur de politesse.
Certaines non conformites n'apparaissent qu'avec des noyaux plus
anciens :
- L'information renvoyee par times(2) et getrusage(2) est par thread
au lieu d'etre globale au processus (corrige dans le noyau 2.6.9).
- Les threads ne partagent pas les limites de ressources (corrige dans
le noyau 2.6.10).
- Les threads ne partagent pas les temporisations d'intervalles
(corrige dans le noyau 2.6.12).
- Seul le thread principal est autorise a demarrer une nouvelle
session avec setsid(2) (corrige dans le noyau 2.6.16).
- Seul le thread principal est autorise a rendre le processus leader
de son groupe de processus avec setpgid(2) (corrige dans le
noyau 2.6.16).
- Les threads ont des parametres de pile specifique de signaux
distincts. Cependant, les parametres de pile specifique d'un nouveau
thread sont copies sur ceux du thread qui l'a cree, et les threads
partagent donc initialement leur pile specifique de signaux (corrige
dans le noyau 2.6.16).
Veuillez noter les points suivants a propos de l'implementation NPTL :
- Si la limite souple de taille de pile (voir dans setrlimit(2) la
description de RLIMIT_STACK) est differente de unlimited, cette
valeur determine la taille de pile par defaut pour les nouveaux
threads. Pour avoir un effet, cette limite doit etre fixee avant le
demarrage du programme, par exemple en utilisant la commande ulimit
-s du shell (limit stacksize dans csh).
D'eterminer l'impl'ementation des threads utilis'ee
Depuis glibc 2.3.2, la commande getconf(1) peut etre utilisee pour
determiner l'implementation de threads du systeme, 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 etre suffisante pour determiner l'implementation de
threads par defaut :
bash$ $( ldd /bin/ls | grep libc.so | awk '{print $3}' ) | \
egrep -i 'threads|nptl'
Native POSIX Threads Library by Ulrich Drepper et al
Choisir l'impl'ementation des threads : LD_ASSUME_KERNEL
Sur les systemes avec une glibc fournissant a la fois LinuxThreads et
NPTL (i.e. glibc 2.3.x), la variable d'environnement LD_ASSUME_KERNEL
peut etre utilisee pour ecraser le choix par defaut d'implementation de
threads fait par l'editeur de liens dynamique. Cette variable indique a
l'editeur de liens dynamique qu'il doit faire comme s'il etait execute
avec une version particuliere du noyau. En indiquant une version du
noyau ne fournissant pas les fonctionnalites necessitees par NPTL, on
peut forcer l'utilisation de LinuxThreads. (La raison la plus probable
pour cela est d'executer une application (boguee) qui depend d'un
comportement de LinuxThreads non conforme a la specification.) 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), proc(5), futex(7), sigevent(7),
signal(7),
et diverses pages de manuel Pthreads, par exemple :
pthread_attr_init(3), pthread_atfork(3), pthread_cancel(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)
COLOPHON
Cette page fait partie de la publication 3.27 du projet man-pages
Linux. Une description du projet et des instructions pour signaler des
anomalies peuvent etre trouvees a l'adresse
<URL:http://www.kernel.org/doc/man-pages/>.
TRADUCTION
Depuis 2010, cette traduction est maintenue a l'aide de l'outil po4a
<URL:http://po4a.alioth.debian.org/> par l'equipe de traduction
francophone au sein du projet perkamon
<URL:http://perkamon.alioth.debian.org/>.
Christophe Blaess <URL:http://www.blaess.fr/christophe/> (1996-2003),
Alain Portal <URL:http://manpagesfr.free.fr/> (2003-2006). Julien
Cristau et l'equipe francophone de traduction de Debian (2006-2009).
Veuillez signaler toute erreur de traduction en ecrivant a
<debian-l10n-french@lists.debian.org> ou par un rapport de bogue sur le
paquet manpages-fr.
Vous pouvez toujours avoir acces a la version anglaise de ce document
en utilisant la commande << man -L C <section> <page_de_man> >>.