Discussion :

[j-jorge]

Bonjour,

J'ai une classe de type gestionnaire de sons qui contient des pointeurs sur des instances d'objets "son". Quand un son se termine, il prévient le gestionnaire qui le supprime alors de sa liste.

Il se peut qu'un son se termine pendant que la liste des sons est parcourue. Dans ce cas, j'ai une suppression qui se fait durant le parcours de la liste, ce qui peut entraîner des catastrophes telles qu'une erreur de segmentation.

Je cherche donc un moyen d'autoriser plusieurs parcours simultanés de la liste en lecture tant qu'aucune modification n'est à faire. En gros, je veux que la suppression dans la liste soit exclusive de tout autre traitement.

Je pensais mettre un mutex sur les lectures et sur la suppression. Cependant, avec une telle solution, je ne peux plus avoir plusieurs lectures simultanées de la liste. J'ai vu sur developpez.com une solution à base de sémaphores et de mutex utilisant Qt. Connaissez-vous une solution qui se passe de Qt ? J'ai bien le mutex de Boost.Thread, mais il ne me semble pas avoir vu de sémaphore.

[r0d]

Bonjour,

j'ai beaucoup réfléchi au sujet, car je veux faire un séquenceur audio un peu particulier pour mon pti jeu.
Et la meilleure solution que je vois, c'est de faire tourner le séquenceur audio dans un thread à part, et de le gérer avec des évènements (par opposition à des appels directs de fonction).
Seulement j'ai l'impression que ça va pas trop cadrer avec ton design :/

C'est pour "Plee the Bear"?

[j-jorge]

Bonjour,

j'ai beaucoup réfléchi au sujet, car je veux faire un séquenceur audio un peu particulier pour mon pti jeu.
Et la meilleure solution que je vois, c'est de faire tourner le séquenceur audio dans un thread à part, et de le gérer avec des évènements (par opposition à des appels directs de fonction).
Seulement j'ai l'impression que ça va pas trop cadrer avec ton design :/

C'est pour "Plee the Bear"?

Oui c'est pour Plee

On a d'autres situations où une liste pourrait être modifiée pendant son parcours. Par exemple, lorsqu'on fait une itération de l'évolution des objets, un objet peut en tuer un autre, qui sera supprimé de la liste. On a résolu ça en reportant la suppression à la fin du parcours. Ça fonctionne bien parce qu'on fait régulièrement un parcours de la liste. Mais pour les sons, ça s'y prête moins. On peut avoir un son qui nous dit « j'ai fini » un peu n'importe quand. Même avec une gestion par événements, il me semble qu'il faudra faire autant attention lors du traitement de l'événement.

Et puis il y a aussi le fait que je voudrais ne pas avoir à revoir tout le module audio L'idéal serait de ne pas avoir à gérer une liste de sons en fait… mais ça pose d'autres soucis.

[3DArchi]

Salut,

Il se peut qu'un son se termine pendant que la liste des sons est parcourue. Dans ce cas, j'ai une suppression qui se fait durant le parcours de la liste, ce qui peut entraîner des catastrophes telles qu'une erreur de segmentation.

Quelque chose doit m'échapper car avec une liste (std::list) un list::erase n'invalide pas les autres itérateurs (sauf bien sûr celui de l'élément modifié). Tu n'as peut être pas moyen de vérifier que l'itérateur à supprimer n'est pas utilisé par ailleurs, peut-être ?

Je cherche donc un moyen d'autoriser plusieurs parcours simultanés de la liste en lecture tant qu'aucune modification n'est à faire. En gros, je veux que la suppression dans la liste soit exclusive de tout autre traitement.

Pattern reader/writer t'irais ?

Je pensais mettre un mutex sur les lectures et sur la suppression. Cependant, avec une telle solution, je ne peux plus avoir plusieurs lectures simultanées de la liste. J'ai vu sur developpez.com une solution à base de sémaphores et de mutex utilisant Qt. Connaissez-vous une solution qui se passe de Qt ? J'ai bien le mutex de Boost.Thread, mais il ne me semble pas avoir vu de sémaphore.

Boost propose ce qu'il faut pour reader/writer (shared_lock, unique_lock, upgrade_lock). Ca devrait suffire ?

[j-jorge]

3DArchi, c'est exactement ça. Le parcours se fait en fait dans une map, mais dans tous les cas je ne sais pas si l'itérateur en cours de lecture n'est pas celui retiré ailleurs.

Pour l'avenir, il s'agit bien du problème des lecteurs et des rédacteurs. Il y a un exemple de solution qui me semble clair ici, il ne me reste plus qu'à comprendre la différence entre boost::upgrade_lock et boost::upgrade_to_unique_lock.