Cadre ou modèle d’application C multithread

J’ai travaillé sur une application multithreadée C (Linux) pendant un certain temps – un enregistreur vidéo qui a des threads pour la capture audio et vidéo, l’encodage, le multiplexage et l’écriture.

J’ai commencé par le regrouper ad hoc en utilisant les opérations de pthread, mais j’essaie maintenant de le développer pour prendre en charge plus d’états et de fragments de code qui apparaissent en double avec le locking, la définition des indicateurs et la signalisation d’une condition. bientôt.

Jusqu’à présent, ce que j’ai imaginé est quelque chose comme ceci:

Chaque thread doit avoir un verrou mutex et deux conditions: l’une pour réveiller le thread et l’autre pour signaler que le thread a fini de travailler sur un autre thread.
Les files d’attente de données sont “possédées” par un certain thread et protégées en utilisant le verrou de ce thread.
Chaque thread a besoin du concept d’états “actif” et “inactif” et de la possibilité de se déplacer entre ceux-ci et le signal lorsqu’il est terminé.

Je prévois de stocker les éléments communs dans une structure et de disposer d’un tableau de ces structures que je peux parcourir pour démarrer, vérifier et arrêter tous les threads.

Comme cela se transforme en un modèle de prise en charge des threads plus générique, je pensais que je risquais de réinventer la roue, alors je demanderais ici s’il existe des modèles connus que je devrais appliquer.

Vos idées me rappellent beaucoup le modèle de calcul d’object actif implémenté dans les frameworks de machine à états QP. Plus précisément, les frameworks QP / C et QP / C ++ ont été portés sur POSIX (qui inclut Linux, BSD, etc.). Le port a été décrit en détail dans la note d’application “QP and Linux” disponible à l’ adresse suivante : http://www.state-machine.com/linux/AN_QP_and_Linux.pdf .

Voici les points forts du port QP vers Linux:

Chaque machine d’état s’exécute dans son propre p-thread. Le p-thread bloque une queue d’événements implémentée avec un mutex et une variable de condition. Lorsque la queue d’événements reçoit un événement, le thread se débloque et l’événement est traité par la machine d’état associée à ce thread. (Ceci est un modèle informatique d’object actif bien connu.)
Les files d’attente d’événements appartiennent aux threads d’object actifs.
Chaque thread a la machine d’état hiérarchique complète, donc il peut avoir des états “actif” ou “inactif”. Les machines à états hiérarchiques (statecharts UML) vous permettent de spécifier des actions et des transitions à un niveau supérieur contrecarre “l’explosion” des transitions d’état que vous avez avec les FSM traditionnels.