Discussion :

[ehmicky]

Salut à tous,
Je suis en train de plancher sur la bibliothèque de gestion de threads de Boost, et j'ai une question à laquelle je ne parviens pas à répondre :
Quelle est l'utilité des classes lock_guard, unique_lock, upgrade_lock et compagnie ?

De ce j'ai compris, il suffit d'instantier un boost::mutex, boost::timed_mutex, boost::shared_mutex, etc. en fonction de ses besoin et de faire appel à lock() et unlock() (ou lock_shared(), etc.). Ca marche très bien comme ça, j'ai essayé avec des centaines de threads en même temps sur plusieurs ressources partagées, et les concepts de propriété exclusive, partagée, upgradable, etc. sont toujours respectés.

Donc du coup, je comprends pas pourquoi on irait s'embêter à instantier un objet boost::lock_guard ou autre pour locker ces mutexs, je vois pas ce que cela apporte en plus.
Est-ce que j'aurais loupé quelque chose ?
Merci ^^

[NoIdea]

Je pense que scope_lock permet de gérer le problème des exceptions (comme les pointeurs intelligents pour les delete). Après, c'est le seul lock dont je me serve donc...

[ehmicky]

Salut,
Merci pour ta réponse,
Il me semble (d'après la documentation de l'API) que scope_lock est un typedef de unique_lock <> avec le type de mutex utilisé (mutex, shared_mutex, etc.) comme paramètre du template. Donc ça m'intéresse, puisque ce qui m'intéresse ce sont les classes définies ici : lock_guard, unique_lock, shared_lock, etc.
En quoi cela aide-t-elle donc par rapport aux risques d'exceptions ?
Sinon, je pense qu'il me manque une compréhension générale de l'utilité de ces classes, par rapport à MUTEX.lock(), MUTEX.unlock(), etc.
Merci !

[gl]

Si ma mémoire est bonne, ce sont des enveloppes RAII pour les mutex.

En quoi cela aide-t-elle donc par rapport aux risques d'exceptions ?
Sinon, je pense qu'il me manque une compréhension générale de l'utilité de ces classes, par rapport à MUTEX.lock(), MUTEX.unlock(), etc.

Si la fonction lève une exception avant le unlock() du mutex, soit celui reste locked (si qui est probablement une erreur), soit tu dois te débrouiller à gérer le cas avec la main ce qui est fastidieux et source d'erreur.
Alors qu'en cas d'exception, les variables locales sont détruites proprement. Dans le cas d'objet lock, le destructeur appel unlock() sur le mutex correspondant. Le mutex est donc bien libéré en cas d'exception sans avoir à le gérer soi-même (il est d'ailleurs également libéré lors de la sortie normale de la fonction, sans appel explicite à unlock).

[ehmicky]

Salut,
Merci, ok j'ai compris ! En gros : utiliser de tels classes, et non les fonctions MUTEX.lock(), etc., car ces dernières ne sont pas exception-safe

J'en profite pour poser une seconde question liée, mais n'étant pas la question originale, si vous le voulez bien :
J'ai déjà manipulé les threads via Glibc, puis SFML, maintenant je pense que Boost est une des meilleurs solutions en la matière (interopérable, efficace, extensible, etc.). A chaque fois, je sais pas trop comment me dépatouiller avec la portée des mes mutexs. Je leur donne une portée globale, pour qu'ils soient partagés par tous les threads, mais il me semble qu'il s'agisse d'une mauvaise pratique. Je me disais donc qu'il fallait peut-être construire une classe gérant tous les mutexs d'une application multi-thread possible, mais j'ignore si c'est une bonne pratique.
Auriez-vous des conseils à me donner en ce qui concerne le design / modélisation de la gestion de la synchronisation des threads ? Merci !

[zul]

Disons qu'avec le pattern RAII, tu n'a pas à gérer la complexité de l'unlocking, si 1/ tu as des exceptions 2/ si tu as plein de conditions de sorties différentes (dans tous les chemins, il faut rajouter un unlock correctement).

Sinon pour la place des mutex, ils doivent être déclarés / initialisés au plus prêt de la ressouce qu'ils protègent