2010-08-24 22 views
2

Y a-t-il des problèmes connus d'initialisation statique des mutex pthread en utilisant PTHREAD_MUTEX_INITIALIZER et en les passant directement pour le verrouillage?L'initialisation statique de pthread_mutex avec PTHREAD_MUTEX_INITIALIZER doit-elle être évitée?

Je lis dans certains sites que ce ne peut pas être garantie sur toutes les plates-formes et aussi dans la page d'aide la note ci-dessous est là:

Remarque: L'initialisation du Mutex à l'aide du PTHREAD_MUTEX_INITIALIZER n'initialise pas immédiatement le mutex. Au lieu de cela, à la première utilisation, les fonctions pthread_mutex_lock() ou pthread_mutex_trylock() se branchent dans un chemin lent et provoquent l'initialisation du mutex. Comme un mutex n'est pas un simple objet mémoire et nécessite que certaines ressources soient allouées par le système, une tentative d'appel de pthread_mutex_destroy() ou de pthread_mutex_unlock() sur un mutex initialisé statiquement à l'aide de PTHREAD_MUTEX_INITIALER et non encore verrouillé provoque une erreur EINVAL . Par conséquent, si deux threads appellent pthread_mutex_lock après l'initialisation statique, cela provoquera-t-il un problème?

Répondre

2

Je pense que ce n'est pas un problème. Étant donné que le thread POSIX définit l'API mais pas l'implémentation. ce n'est pas un problème si certaines implémentations choisissent une approche particulière. Mais le bon comportement d'appeler pthread_mutex_lock devrait être garanti.