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)