[Actualités]
Test Middle-earth: Shadow of Mordor Game of the Year Edition (Nintendo Switch 2)
[Actualités]
Vous avez un vieux téléphone Android ? Ils viennent de lui trouver une utilisa...
[Actualités]
Avez-vous un routeur fourni par votre FAI ? Le mot de passe Wi-Fi ne vous sera p...
[Actualités]
Sony dit adieu aux disques, Microsoft pourrait bien les sauver. Qui l'eût cru ?
[Actualités]
Linux a obtenu la note de 9,3 sur 10. Malheureusement, cela correspond à une no...
[Actualités]
DLSS 5 sur les cartes AMD ? La nouvelle version du mod ajoute des fonctionnalitÃ...
[Actualités]
Vela Maps, l'application open source qui ressemble à Google Maps mais protège ...
[Actualités]
Microsoft Edge repense les mises à jour : un prototype les applique en arrière...
[Actualités]
Microsoft a abandonné Publisher, mais vos anciens fichiers PUB ne sont pas perdus
[Actualités]
Apple a ouvert les précommandes pour le smartphone iPhone Duo.
[Articles]
Mao tome 24
[Articles]
Middle-earth: Shadow of War Definitive Edition
[Articles]
Middle-earth: Shadow of Mordor Game of the Year Edition
[Articles]
Faire face au « bombardement » par mails ! ESET explique
[Articles]
American Parano tome 4 : Burn, Hollywood, burn !
[Articles]
Gear.Club Unlimited 3
[Articles]
Tormented Souls II
[Articles]
Clive Barker's Hellraiser : Revival
[Articles]
Previder renforce sa position en Belgique avec l’acquisition d’AppSys ICT Group
[Articles]
Hero Organization tome 3
Se connecter
Se connecter
Inscription
Mot de passe perdu
Connexion
Actualités
Lettre d'information
Proposer une actualité
Archives
Actualités
Articles
Programmation
Press Release
Matériel
Logiciels
Livres
Bandes Dessinées
Interviews
Derniers commentaires
Jeux Vidéos
PC
PlayStation 5
Xbox Series X
Nintendo Switch 2
Nintendo Switch
PlayStation 4
Autres plateformes
Forum
Derniers messages
Informatique
Fun
Divers
Logithèque
Blogs
Divers
A Propos
Annonceurs
Contact
Recherche
RSS
Se connecter
Se connecter
Inscription
Mot de passe perdu
Connexion
Editer un article
Titre
Mots Clés
Texte
[size=18] [b]Nom[/b] [/size] pthread_cond_init, pthread_cond_destroy, pthread_cond_signal, pthread_cond_broadcast, pthread_cond_wait, pthread_cond_timedwait - opérations sur les conditions. [size=18] [b]Résumé[/b] [/size] [b]#include
[/b] [b][i]pthread_cond_t cond = PTHREAD_COND_INITIALIZER;[/i][/b] [b][i]int pthread_cond_init(pthread_cond_t * cond , pthread_condattr_t * cond_attr );[/i][/b] [b][i]int pthread_cond_signal(pthread_cond_t * cond );[/i][/b] [b][i]int pthread_cond_broadcast(pthread_cond_t * cond );[/i][/b] [b][i]int pthread_cond_wait(pthread_cond_t * cond , pthread_mutex_t * mutex );[/i][/b] [b][i]int pthread_cond_timedwait(pthread_cond_t * cond , pthread_mutex_t * mutex , const struct timespec * abstime );[/i][/b] [b][i]int pthread_cond_destroy(pthread_cond_t * cond );[/i][/b] [size=18] [b]Description[/b] [/size] Une condition (abréviation pour variable-condition) est un mécanisme de syncrhonisation permettant à un thread de suspendre son exécution juqu'à ce qu'une certaine condition (un prédicat) soit vérifiée. Les opérations fondamentales sur les conditions sont : signaler la condition (quand le prédicat devient vrai), et attendre la condition en suspendant l'exécution du thread jusqu'à ce qu'un autre thread signale la condition. Une variable condition doit toujours être associée à un mutex, pour éviter les accès concurrents où un thread se prépare à attendre une condition et un autre signale la condition juste avant que le premier n'attende réellement. [b]pthread_cond_init[/b] initialise la variable condition [b]cond ,[/b] en utilisant les attributs de condition spécifiés par [b]cond_attr ,[/b] ou les attributs par défaut si [i]cond_attr[/i] vaut [b]NULL .[/b] L'implémentation LinuxThreads ne supporte aucun attribut de conditions, aussi le paramètre [i]cond_attr[/i] est-il pour l'instant ignoré. Les variables de type [b]pthread_cond_t[/b] peuvent également être statiquement initialisées, en utilisant la constante [b]PTHREAD_COND_INITIALIZER .[/b] [b]pthread_cond_signal[/b] relance l'un des threads attendant la variable condition [b]cond .[/b] S'il n'existe aucun thread répondant à ce critière, rien ne se produit. Si plusieurs threads attendent sur [b]cond ,[/b] seul l'un d'entre eux sera relancé, mais il est impossible de savoir lequel. [b]pthread_cond_broadcast[/b] relance tous les threads attendant sur la variable condition [b]cond .[/b] Rien ne se passe s'il n'y a aucun thread attendant sur [b]cond .[/b] [b]pthread_cond_wait[/b] déverrouille atomiquement le [i]mutex[/i] (comme [b]pthread_unlock_mutex )[/b] et attend que la variable condition [i]cond[/i] soit signalée. L'exécution du thread est suspendue et ne consomme pas de temps CPU jusqu'à ce que la variable condition soit signalée. Le [i]mutex[/i] doit être verrouillé par le thread appelant à l'entrée de [b]pthread_cond_wait .[/b] Avant de rendre la main au thread appelant, [b]pthread_cond_wait[/b] reverrouille [i]mutex[/i] (comme [b]pthread_lock_mutex ).[/b] Le déverouillage du mutex et la suspension de l'exécution sur la variable condition sont liés atomiquement. Donc, si tous les threads verrouillent le mutex avant de signaler la condition, il est garanti que la condition ne peut être signalée (et donc ignorée) entre le moment où un thread verrouille le mutex et le moment où il attend sur la variable condition. [b]pthread_cond_timedwait[/b] déverrouille le [i]mutex[/i] et attend sur [b]cond ,[/b] en liant atomiquement ces deux étapes, comme le fait [b]pthread_cond_wait ,[/b] cependant l'attente est bornée temporellement. Si [i]cond[/i] n'a pas été signalée après la période spécifiée par [b]abstime ,[/b] le mutex [i]mutex[/i] est reverrouillé et [b]pthread_cond_timedwait[/b] rend la main avec l'erreur [b]ETIMEDOUT .[/b] Le paramètres [i]abstime[/i] spécifie un temps absolu, avec la même origine que [b]time (2)[/b] et [b]gettimeofday (2):[/b] un [i]abstime[/i] de 0 correspond à 00:00:00 GMT, le 1er Janvier 1970. [b]pthread_cond_destroy[/b] détruit une variable condition, libérant les ressources qu'elle possède. Aucun thread ne doit attendre sur la condition à l'entrée de [b]pthread_cond_destroy .[/b] Dans l'implémentation LinuxThreads, aucune ressource ne peut être associée à une variable condition, aussi [b]pthread_cond_destroy[/b] ne fait en fait rien d'autre que vérifier qu'aucun thread n'attend la condition. [size=18] [b]Annulation[/b] [/size] [b]pthread_cond_wait[/b] et [b]pthread_cond_timedwait[/b] sont des points d'annulation. Si un thread est annulé alors qu'il est suspendu dans l'une de ces fonctions, son exécution reprend immédiatement, reverrouillant l'argument [i]mutex[/i] à [b]pthread_cond_wait[/b] et [b]pthread_cond_timedwait ,[/b] et exécute finalement l'annulation. Aussi, les gestionnaires d'annulation sont assurés d'être exécutés alors que [i]mutex[/i] est verrouillé. [size=18] [b]Fiabilite par rapport aux signaux asynchrones[/b] [/size] Ces fonctions ne sont pas fiables par rapport aux signaux asynchrones et ne doivent donc pas être utilisées dans des gestionnaires de signaux [Ndt: sous peine de perder leur propriété d'atomicité]. En particulier, appeler [b]pthread_cond_signal[/b] ou [b]pthread_cond_broadcast[/b] dans un gestionnaire de signal peut placer le thread appelant dans une situation de blocage définitif. [size=18] [b]Valeur renvoyée[/b] [/size] Toutes ces fonctions renvoient 0 en cas de succès et un code d'erreur non nul en cas de problème. [size=18] [b]Erreurs[/b] [/size] [b]pthread_cond_init ,[/b] [b]pthread_cond_signal ,[/b] [b]pthread_cond_broadcast ,[/b] et [b]pthread_cond_wait[/b] ne renvoient jamais de code d'erreur. La fonction [b]pthread_cond_timedwait[/b] renvoie l'un des codes d'erreur suivants en cas de problème :[table][row][col] [/col][col] [b]ETIMEDOUT[/b] [table][row][col] [/col][col]La variable-condition n'a pas reçu de signal avant le délai spécifié par [i]abstime[/i] [/col][/row][/table] [b]EINTR[/b] [b]pthread_cond_timedwait[/b] [table][row][col] [/col][col]a été interrompu par un signal[/col][/row][/table] La fonction [b]pthread_cond_destroy[/b] renvoie l'un des codes d'erreur suivants en cas de problème :[table][row][col] [/col][col][/col][/row][/table] [b]EBUSY[/b] [table][row][col] [/col][col]il existe des threads attendant [b]cond .[/b][/col][/row][/table] [/col][/row][/table] [size=18] [b]Auteur[/b] [/size] Xavier Leroy
[size=18] [b]Voir aussi[/b] [/size] [b]pthread_condattr_init (3),[/b] [b]pthread_mutex_lock (3),[/b] [b]pthread_mutex_unlock (3),[/b] [b]gettimeofday (2),[/b] [b]nanosleep (2).[/b] [size=18] [b]Exemple[/b] [/size] Considérons deux variables globales partagées [i]x[/i] et [b]y ,[/b] protégées par le mutex [b]mut ,[/b] et une variable condition [i]cond[/i] pour signaler que [i]x[/i] devient plus grand que [b]y .[/b] [table][row][col] [/col][col] .ft 3 .nf int x,y; pthread_mutex_t mut = PTHREAD_MUTEX_INITIALIZER; pthread_cond_t cond = PTHREAD_COND_INITIALIZER; .ft [/col][/row][/table] .fi Attendre que [i]x[/i] devienne plus grand que [i]y[/i] se réalise de la manière suivante: [table][row][col] [/col][col] .ft 3 .nf pthread_mutex_lock(&mut); while (x <= y) { pthread_cond_wait(&cond, &mut); } /* agir sur x et y */ pthread_mutex_unlock(&mut); .ft [/col][/row][/table] .fi Les modifications de [i]x[/i] et [i]y[/i] qui peuvent rendre [i]x[/i] plus grand que [i]y[/i] doivent signaler la condition si nécessaire: [table][row][col] [/col][col] .ft 3 .nf pthread_mutex_lock(&mut); /* modifer x et y */ if (x > y) pthread_cond_broadcast(&cond); pthread_mutex_unlock(&mut); .ft [/col][/row][/table] .fi S'il peut être prouvé qu'au plus un thread en attente nécessite d'être réveillé (par exemple, s'il n'y a que deux threads communicant via [i]x[/i] et [b]y ),[/b] [b]pthread_cond_signal[/b] peut être utilisé en tant qu'alternative efficace à [b]pthread_cond_broadcast .[/b] En cas de doute, utilisez [b]pthread_cond_broadcast .[/b] Pour attendre que [i]x[/i] devienne plus grand que [i]y[/i] avec un timeout de 5 secondes, faîtes: [table][row][col] [/col][col] .ft 3 .nf struct timeval now; struct timespec timeout; int retcode; pthread_mutex_lock(&mut); gettimeofday(&now); timeout.tv_sec = now.tv_sec + 5; timeout.tv_nsec = now.tv_usec * 1000; retcode = 0; while (x <= y && retcode != ETIMEDOUT) { retcode = pthread_cond_timedwait(&cond, &mut, &timeout); } if (retcode == ETIMEDOUT) { /* timeout */ } else { /* agir sur x et y */ } pthread_mutex_unlock(&mut); .ft [/col][/row][/table] .fi [size=18] [b]Traduction[/b] [/size] [i]Thierry Vignaud < tvignaud@mandrakesoft.com >, 2000[/i]
Fichier
Newsletter
Recevez les dernières actualités tech directement dans votre boîte mail.
S'inscrire
Forum
-
Derniers messages
Réseaux et Télécom
Edpnet
Bavardages
Séries TV, vous regardez quoi?
Bavardages
Aujourd'hui, je rénove ou je construis ^^
Informations
Besoin d’avis sur l’UX de mon mini-projet web (et plus globalement sur ce qui vous rebute sur un site) ?
Software
problème sur windows 10
Réseaux et Télécom
Problème wifi (POE)
Software
Postfix - Need help
Bavardages
Oh râge oh désespoir !
Programmation
Enregistrement client et envoi mail
Software
SÉCURITÉ MACBOOK
Actualités
-
Archives
Jeux Vidéos
19-10
Test Middle-earth: Shadow of Mordor Game of the Year Edition (Nintendo Switch 2)
Mobile
19-10
Vous avez un vieux téléphone Android ? Ils viennent de lui trouver une utilisation géniale.
Matériel
19-10
Avez-vous un routeur fourni par votre FAI ? Le mot de passe Wi-Fi ne vous sera peut-être pas très utile.
Consoles
19-10
Sony dit adieu aux disques, Microsoft pourrait bien les sauver. Qui l'eût cru ?
Linux
19-10
Linux a obtenu la note de 9,3 sur 10. Malheureusement, cela correspond à une note indiquant une faille de sécurité.
Ada
CSS
Cobol
CPP
HTML
Fortran
Java
JavaScript
Pascal
Perl
PHP
Python
SQL
VB
XML
Anon URL
DailyMotion
eBay
Flickr
FLV
Google Video
Google Maps
Metacafe
MP3
SeeqPod
Veoh
Yahoo Video
YouTube
6px
8px
10px
12px
14px
16px
18px
Informaticien.be
- © 2002-2026
Akretio
SRL - Generated via
Kelare
Haut de page