Editer un article - Informaticien.be

Editer un article

Titre
Mots Clés
Texte	[size=18] [b]Nom[/b] [/size] sem_init, sem_wait, sem_trywait, sem_post, sem_getvalue, sem_destroy - opérations sur les sémaphores. [size=18] [b]Résumé[/b] [/size] [b]#include <semaphore.h>[/b] [b][i]int sem_init(sem_t * sem , int pshared , unsigned int valeur );[/i][/b] [b][i]int sem_wait(sem_t * sem );[/i][/b] [b][i]int sem_trywait(sem_t * sem );[/i][/b] [b][i]int sem_post(sem_t * sem );[/i][/b] [b][i]int sem_getvalue(sem_t * sem , int * sval );[/i][/b] [b][i]int sem_destroy(sem_t * sem );[/i][/b] [size=18] [b]Description[/b] [/size] Cette page de manuel documente les sémaphores du standard POSIX 1003.1b, à ne pas confondre avec ceux des IPC Système V tels que décrits par [b]ipc (5),[/b] [b]semctl (2)[/b] et [b]semop (2).[/b] Les sémaphores sont des compteurs pour les ressources partagées par plusieurs threads. Les opérations de base sur les sémaphores sont :[table][row][col]    [/col][col] [table][row][col]    [/col][col]incrémenter le compteur de manière atomique[/col][/row][/table] [table][row][col]    [/col][col]attendre que le compteur soit non-nul et décrémenter le compteur de manière atomique.[/col][/row][/table] [b]sem_init[/b] initialise le sémaphore pointé par [b]sem .[/b] Le compteur associé au sémaphore est initialisé à [b]valeur .[/b] L'argument [i]pshared[/i] indique si le sémaphore est local au processus courrant ([i]pshared[/i] est zéro) ou partagé entre plusieurs processus ([i]pshared[/i] n'est pas nulle). LinuxThreads ne gère actuellement pas les sémaphores partagés entre plusieurs processus, donc [b]sem_init[/b] renvoie toujours l'erreur [b]ENOSYS[/b] si [i]pshared[/i] n'est pas nul. [b]sem_wait[/b] suspend le thread appelant jusqu'à ce que le sémaphore pointé par [i]sem[/i] ait un compteur non nul. Alors, le compteur du sémaphore est atomiquement décrémenté. [b]sem_trywait[/b] est une variante non bloquante de [b]sem_wait .[/b] Si le sémaphore pointé par [i]sem[/i] a une valeur non nulle, le compteur est atomiquement décrémenté et [b]sem_trywait[/b] retourne immédiatement 0. Si le compteur du sémaphore est zéro, [b]sem_trywait[/b] retourne immédiatement en indiquant l'erreur [b]EAGAIN .[/b] [b]sem_post[/b] incrémente atomiquement le compteur du sémaphore pointé par [b]sem .[/b] Cetts fonction ne bloque jamais et peut être utilisée de manière fiable dans un gestionnaire de signaux. [b]sem_getvalue[/b] sauvegarde à l'emplacement pointé par [i]sval[/i] la valeur courrante du compteur du sémaphore [b]sem .[/b] [b]sem_destroy[/b] détruit un sémaphore, libérant toutes les ressources qu'il possédait. Aucun thread ne doit être bloqué sur ce sémaphore quand [b]sem_destroy[/b] est appelée. Dans l'implémentation LinuxThreads, aucune ressource ne peut être associée à un sémaphore, donc [b]sem_destroy[/b] ne fait actuellement rien si ce n'est vérifier qu'aucun thread n'est bloqué sur ce sémaphore. [/col][/row][/table] [size=18] [b]Annulation[/b] [/size] [b]sem_wait[/b] est un point d'annulation. [size=18] [b]Signaux asynchrone[/b] [/size] Sur les processeurs proposant une opération test_et_échange (Intel 486, Pentium+, Alpha, PowerPC, MIPS II, Motorola 68k), la fonction [b]sem_post[/b] est atomique en ce qui concerne le traitement ds signaux asynchrones. Elle peut donc être appelée par un gestionnaire de signal. C'est la seule fonction de synchronisation de threads définie par POSIX qui soit réentrante vis-à-vis des signaux asynchrones. Sur les Intel 386 et les Sparc, l'implémentation courante de [b]sem_post[/b] par LinuxThreads n'est pas atomique car le langage machine ne fournit pas d'instructions atomiques. L'utilisation de sem_post dans un gestionnaire de signal n'est donc pas fiable, deux signaux simultanés pouvant amener à n'enregistrer qu'une seule action. [size=18] [b]Valeur renvoyée[/b] [/size] Les fonctions [b]sem_wait[/b] et [b]sem_getvalue[/b] renvoient toujours 0. Toutes les autres fonctions relatives aux sémaphores renvoient zéro en cas de succès et -1 en cas d'erreur. Dans ce dernier cas, la variable [b]errno[/b] est positionné au code d'erreur correspondant. [size=18] [b]Erreurs[/b] [/size] La fonction [b]sem_init[/b] remplit [b]errno[/b] avec l'un des codes d'erreur suivants :[table][row][col]    [/col][col] [b]EINVAL[/b] [i]valeur[/i] [table][row][col]    [/col][col]dépasse la valeur maximale du compteur. [b]SEM_VALUE_MAX[/b][/col][/row][/table] [b]ENOSYS[/b] [i]pshared[/i] [table][row][col]    [/col][col]n'est pas zéro.[/col][/row][/table] La fonction [b]sem_trywait[/b] remplit [b]errno[/b] avc l'un des codes d'erreur suivants :[table][row][col]    [/col][col][/col][/row][/table] [b]EAGAIN[/b] [table][row][col]    [/col][col]le compteur du sémaphore vaut actuellement 0.[/col][/row][/table] La fonction [b]sem_post[/b] remplit [b]errno[/b] avec l'un des codes d'erreur suivants :[table][row][col]    [/col][col][/col][/row][/table] [b]ERANGE[/b] [table][row][col]    [/col][col]après l'incrémentation, la valeur du sémaphore aurait dépassé [b]SEM_VALUE_MAX[/b] (Le compteur du sémaphore n'est pas modifié dans ce cas)[/col][/row][/table] La fonction [b]sem_destroy[/b] remplit [b]errno[/b] avec l'un des codes d'erreur suivants :[table][row][col]    [/col][col][/col][/row][/table] [b]EBUSY[/b] [table][row][col]    [/col][col]certains threads sont actuellement bloqués en attente sur le sémaphore.[/col][/row][/table] [/col][/row][/table] [size=18] [b]Auteur[/b] [/size] Xavier Leroy <Xavier.Leroy@inria.fr> [size=18] [b]Voir aussi[/b] [/size] [b]pthread_mutex_init (3),[/b] [b]pthread_cond_init (3),[/b] [b]pthread_cancel (3),[/b] [b]ipc (5).[/b] [size=18] [b]Traduction[/b] [/size] [i]Thierry Vignaud < tvignaud@mandrakesoft.com >, 2000[/i]
Fichier