2010-10-15 6 views
2

J'écris un programme avec quelques sections critiques. La chose est que j'ai besoin de vérifier la valeur d'un mutex dans une instruction if.C Pthreads valeurs de mutex?

Je voudrais faire quelque chose comme ceci:

if pthread_mutex(&mutex) == 0 // locked 
    // Do something 
else if pthread_mutex(&mutex) == 1 // unlocked 
// Do something else 

Est-ce possible?

Répondre

6

Vous souhaitez pthread_mutex_trylock().

A partir de ce lien:

La fonction pthread_mutex_trylock() est équivalent à pthread_mutex_lock(), sauf que si l'objet mutex référencé par mutex est actuellement verrouillé (par un fil, y compris le fil en cours), l'appel doit revenir immédiatement. ... Valeurs de retour ... La fonction pthread_mutex_trylock() retourne zéro si un verrou sur l'objet mutex référencé par mutex est acquise. Dans le cas contraire, un numéro d'erreur est retourné pour indiquer l'erreur

donc votre code irait comme ceci:

pthread_mutex_t *m = /* ... */; 

if (pthread_mutex_trylock(m) == 0) 
{ 
    /* Success! This thread now owns the lock. */ 
} 
else 
{ 
    /* Fail! This thread doesn't own the lock. Do something else... */ 
} 
+0

Oui, en cas de succès, déverrouillez à nouveau. PS: Je me suis battu avec elle hier: http://stackoverflow.com/questions/3931026/how-can-i-synchronize-three-threads – slashmais

+0

Merci! Je suis à peu près sûr que cela fonctionnera bien. –

+0

Puis-je évaluer le verrou et ne pas le verrouiller? Je voudrais évaluer un verrou, puis lever un sem_wait/post en fonction d'un verrou. –

0

Si vous voulez savoir si votre mutex est déjà verrouillé, je vous suggère d'utiliser pthread_mutex_trylock. Gardez à l'esprit que le verrouillage d'un mutex est une opération lourde, vous ne devriez pas le verrouiller juste pour tester si ce n'était pas le cas.

2

Non, vous ne devriez pas essayer de le faire. Je pense que les mutex pthread sont faits pour réguler l'accès local à certaines ressources critiques, et si à un endroit votre programme ne sait pas si ce thread détient le verrou, vous utilisez le mauvais outil. Je vois deux alternatives:

  • garder une variable sur la pile de la fonction où vous garder une trace qu'il est bloqué ici, ou si vraiment nécessaire stocker l'ID de fil et de comparer à que
  • commutateur à sem_t comme contrôle DS. ils n'ont pas cette restriction d'être collés à un fil spécifique que "détient" eux, mais sont basés sur jeton, donc tout thread qui obtient le jeton peut faire le travail qui est requis. (mais soyez prudent et vérifiez la valeur de retour des fonctions, ces routines peuvent être interrompues.)
+0

J'essaie d'utiliser une combinaison des deux, c'est assez troublant pour résoudre le problème. Je pourrais avoir besoin de retravailler toute la solution. –