attributes(7) Miscellaneous Information Manual attributes(7)
NOM
attributes - Concepts de securite POSIX
DESCRIPTION
Note : le texte de cette page de manuel est basee sur des elements pris
dans la section << POSIX Safety Concepts >> du manuel de la
bibliotheque GNU C. Plus de details sur les sujets decrits ici peuvent
etre trouves dans ce manuel.
Diverses pages de manuel de fonctions comportent une section ATTRIBUTES
qui decrit la securite de l'appel d'une fonction dans divers contextes.
Cette section annote les fonctions avec les balises de securite
suivantes :
MT-Safe
Les fonctions MT-Safe ou Thread-Safe sont sures a appeler en
presence d'autres threads. MT, dans MT-Safe, signifie
<< multithread >>.
L'etat MT-Safe n'implique pas qu'une fonction est atomique, ni
qu'elle utilise un des mecanismes de synchronisation de memoire
que POSIX expose aux utilisateurs. Il est meme possible que
l'appel de plusieurs fonctions MT-Safe a la suite ne produise
pas une combinaison MT-Safe. Par exemple, le fait qu'un thread
appelle deux fonctions MT-Safe l'une immediatement apres l'autre
ne garantit pas un comportement equivalent a l'execution
atomique de la combinaison des deux fonctions, dans la mesure ou
des appels concomitants dans d'autres threads peuvent interferer
de maniere destructive.
Les optimisations a l'echelle du programme qui peuvent integrer
des fonctions a travers les interfaces des bibliotheques peuvent
exposer a des reorganisations non sures, aussi il n'est pas
recommande de realiser des integrations au moyen des interfaces
de la bibliotheque GNU C. L'etat documente MT-Safety n'est pas
garanti. Neanmoins, les fonctions definies dans les en-tetes
visibles par l'utilisateur sont concues pour etre sures pour
l'integration.
MT-Unsafe
Les fonctions MT-Unsafe ne sont pas sures pour des appels dans
des programmes multithreades.
D'autres mots-clefs qui apparaissent dans des notes de surete sont
definis dans les sections suivantes.
Fonctionnalites sures sous condition
Pour certaines fonctionnalites qui rendent non sure l'appel de
certaines fonctions dans certains contextes, il existe des moyens
connus pour eviter un probleme autres que de s'abstenir completement
d'appeler la fonction. Les mots-cles qui suivent font reference a ces
fonctionnalites et chacune des definitions indique comment le programme
dans son ensemble doit etre contraint de maniere a supprimer le
probleme de surete indique par le mot-cle. C'est seulement lorsque
toutes les raisons qui rendent une fonction non sure ont ete observees
et traitees, en appliquant les contraintes documentees, que l'appel
d'une fonction devient sur dans un contexte.
init Les fonctions marquees init en tant que fonctionnalite MT-Unsafe
realisent une initialisation MT-Unsafe quand elles sont appelees
en premier.
L'appel d'une fonction de ce type au moins une fois en mode
monothread supprime cette raison specifique qui fait considerer
la fonction comme MT-Unsafe. S'il ne reste pas d'autre raison,
la fonction peut alors etre appelee de facon sure apres le
demarrage d'autres threads.
race Les fonctions marquees race en tant que probleme d'etat MT-Safe
operent sur des objets d'une facon qui peut provoquer des
situations de concurrences de donnees ou des formes similaires
d'interferences destructives provoquees par une execution
concurrente. Dans certains cas, les objets sont passes aux
fonctions par les utilisateurs ; dans d'autres, ils sont
utilises par les fonctions pour renvoyer des valeurs aux
utilisateurs ; dans d'autres encore, ils ne sont meme pas
exposes aux utilisateurs.
const Les fonctions marquees const en tant que probleme d'etat MT-Safe
modifient de facon non-atomique les objets internes qui sont
plutot a considerer comme constants, parce qu'une partie
importante de la bibliotheque GNU C y accede sans
synchronisation. A la difference de race qui fait qu'a la fois
lecteurs et ecrivains d'objets internes sont consideres comme
MT-Unsafe, cette marque ne s'applique qu'aux ecrivains. Leur
appel demeure MT-Unsafe, mais le caractere constant alors
obligatoire des objets qu'ils modifient permet de considerer les
lecteurs comme MT-safe (aussi longtemps qu'il n'y a pas d'autre
raison pour qu'ils soient non surs), dans la mesure ou l'absence
de synchronisation n'est pas un probleme quand les objets sont
effectivement constants.
L'identifiant qui suit la marque const apparaitra lui-meme conne
une note de surete dans les lecteurs. Les programmes qui
souhaitent contourner ce probleme de surete, afin d'appeler les
ecrivains, peuvent utiliser un verrou en lecture et ecriture non
recursif associe a l'identifiant et garder la totalite des
appels a des fonctions marquees const suivies de l'identifiant
avec un verrou en ecriture et la totalite des appels a des
fonctions marquees par l'identifiant lui-meme avec un verrou en
lecture.
sig Les fonctions marquees sig en tant que probleme d'etat MT-Safe
peuvent installer de facon temporaire un gestionnaire de signal
a des fins internes qui peut interferer avec d'autres usages du
signal, identifie apres deux-points.
Le probleme de surete peut etre contourne en s'assurant qu'aucun
autre usage du signal n'interviendra pendant la duree de
l'appel. Il est recommande de maintenir un mutex non recursif
pendant l'appel de toutes les fonctions qui utilisent le meme
signal temporaire, de bloquer ce signal avant l'appel et de
reinitialiser son gestionnaire apres.
term Les fonctions marquees term en tant que probleme d'etat MT-Safe
peuvent modifier la configuration du terminal de la facon
recommandee, c'est-a-dire : appel de tcgetattr(3), modification
de certains attributs puis appel de tcsetattr(3), cela cree une
fenetre dans laquelle les modifications effectuees par d'autres
threads sont perdues. Donc, les fonctions marquees term sont
MT-Unsafe.
Il est donc recommande d'eviter, pour les applications utilisant
le terminal, des interactions simultanees et reentrantes avec
lui en nel'utilisant pas dans les gestionnaires de signal ou les
signaux bloquants qui pourraient l'utiliser egalement, et de
maintenir un verrou pendant l'utilisation de ces fonctions et
l'interaction avec le terminal. Ce verrou devrait egalement etre
utilise pour l'exclusion mutuelle avec les fonctions marquees
race:tcattr(fd) ou fd est un descripteur de fichier pour le
terminal de controle. L'appelant peut utiliser un mutex unique
pour simplifier ou utiliser un mutex par terminal meme s'ils
sont references par des descripteurs de fichier differents.
Autres remarques sur la surete
Des mots clefs supplementaires peuvent etre ajoutes aux fonctions,
indiquant des fonctionnalites qui ne rendent pas la fonction non sure a
appeler, mais il peut etre necessaire d'en tenir compte dans certaines
classes de programmes.
locale Les fonctions marquees locale en tant que probleme d'etat
MT-Safe lisent a partir de l'objet locale sans aucune forme de
synchronisation. Ces fonctions appelees en meme temps que des
modifications de locale peuvent se comporter d'une maniere qui
ne correspond a aucune des locales actives pendant leur
execution mais a un melange imprevisible de celles-ci.
Nous ne marquons pas ces fonctions comme MT-Unsafe neanmoins,
car les fonctions qui modifient l'objet locale sont marquees
const:locale et considerees comme non sures. Etant non sures,
ces dernieres ne doivent pas etre appelees quand plusieurs
threads sont en execution ou lorsque les signaux asynchrones
sont actives, et ainsi la locale peut etre consideree comme
effectivement constante dans ces contextes, ce qui rend les
premieres fonctions sures.
env Les fonctions marquees env en tant que probleme d'etat MT-Safe
accedent a l'environnement avec getenv(3) ou une commande
similaire sans aucune protection pour garantir la surete en
presence de modifications simultanees.
Nous ne marquons pas ces fonctions comme MT-Unsafe neanmoins,
car les fonctions qui modifient l'environnement sont toutes
marquees const:env et considerees comme non sures. Etant non
sures, ces dernieres ne doivent pas etre appelees quand
plusieurs threads sont en execution ou lorsque les signaux
asynchrones sont actives, et ainsi l'environnement peut etre
considere comme effectivement constant dans ces contextes, ce
qui rend les premieres fonctions sures.
hostid Les fonctions marquees hostid en tant que probleme d'etat
MT-Safe lisent a partir des structures de donnees communes a
tout le systeme qui contiennent << l'ID d'hote >> de la machine.
Ces structures de donnees ne peuvent pas en general etre
modifiees automatiquement. Dans la mesure ou il est attendu que
normalement << l'ID d'hote >> ne change pas, la fonction qui lit
a partir d'elle (gethostid(3)) est consideree comme sure, tandis
que la fonction qui la modifie (sethostid(3)) est marquee
const:hostid, indiquant qu'elle requiert une attention
particuliere si elle doit etre appelee. Dans ce cas particulier,
cette attention particuliere equivaut a une coordination a
l'echelle de l'ensemble du systeme (pas seulement a l'interieur
du processus).
sigintr
Les fonctions marquees sigintr en tant que probleme d'etat
MT-Safe accedent a la structure de donnees interne _sigintr de
la bibliotheque GNU C sans aucune protection pour garantir la
surete en presence de modifications simultanees.
Nous ne marquons pas ces fonctions comme MT-Unsafe neanmoins,
car les fonctions qui modifient cette structure de donnees sont
toutes marquees const:sigintr et considerees comme non sures.
Etant non sures, ces dernieres ne doivent pas etre appelees
quand plusieurs threads sont en execution ou lorsque les signaux
asynchrones sont actives, et ainsi l'environnement peut etre
considere comme effectivement constant dans ces contextes, ce
qui rend les premieres fonctions sures.
cwd Les fonctions marquees cwd en tant que probleme d'etat MT-Safe
peuvent changer temporairement le repertoire actif actuel durant
leur execution ce qui fait que les noms de chemin relatifs
peuvent etre resolus de facon inattendue dans les autres threads
ou dans les gestionnaires de signal ou d'annulation asynchrones.
Ce n'est pas une raison suffisante pour marquer comme MT-Unsafe
les fonctions ainsi marquees, mais quand ce comportement est
optionnel (par exemple, nftw(3) avec FTW_CHDIR), eviter l'option
peut etre une bonne alternative a l'utilisation des noms de
chemin complets ou d'appels systeme relatifs au descripteur de
fichier (par exemple, openat(2)).
:identifiant
Les annotations peuvent parfois etre suivies par des
identifiants destines a regrouper plusieurs fonctions qui, par
exemple accedent aux structures de donnees de facon non sure,
comme dans race et const, ou pour fournir des informations plus
specifiques, comme le nom d'un signal dans une fonction marquee
sig. Il est envisage que cela pourrait aussi etre applique a
l'avenir a lock et corrupt.
Dans la plupart des cas, l'identifiant designera un ensemble de
fonctions, mais il peut designer des objets globaux ou des
parametres de fonction, des proprietes identifiables ou des
composants logiques qui leur sont associes, avec une notation du
type, par exemple, :buf(param) pour designer un tampon associe
au parametre param, ou :tcattr(fd) pour designer les attributs
de terminal d'un descripteur de fichier fd.
L'utilisation la plus courante des identifiants est de fournir
des groupes logiques de fonctions et de parametres qui
necessitent d'etre proteges par la meme primitive de
synchronisation afin d'assurer une operation sure dans un
contexte donne.
/condition
Certaines annotations de surete peuvent etre conditionnelles,
dans le sens qu'elles ne s'appliquent que si une expression
booleenne comprenant des parametres, des variables globales ou
meme le noyau sous-jacent est evaluee vraie. Par exemple, /!ps
et /one_per_line indiquent que le marqueur qui precede ne
s'applique que si l'argument ps est NULL ou la variable globale
one_per_line est differente de zero.'
Quand toutes les marques qui rendent non sure une fonction sont
agrementees de conditions de ce type, et qu'aucune des
conditions nommees ne tient, alors, la fonction peut etre
consideree comme sure.
VOIR AUSSI
pthreads(7), signal-safety(7)
TRADUCTION
La traduction francaise de cette page de manuel a ete creee par
Christophe Blaess , Stephan Rafin
, Thierry Vignaud ,
Francois Micaux, Alain Portal , Jean-Philippe
Guerard , Jean-Luc Coulon (f5ibh) , Julien Cristau , Thomas
Huriaux , Nicolas Francois
, Florentin Duneau
, Simon Paillard , Denis Barbier , David Prevot
et Jean-Pierre Giraud
Cette traduction est une documentation libre ; veuillez vous reporter a
la GNU General Public License version 3
concernant les conditions
de copie et de distribution. Il n'y a aucune RESPONSABILITE LEGALE.
Si vous decouvrez un bogue dans la traduction de cette page de manuel,
veuillez envoyer un message a .
Pages du manuel de Linux 6.06 1 novembre 2023 attributes(7)