Discussion :

[Marloon]

Bonjour,

je me permets de solliciter votre aide car je suis face à un problème concernant l'implémentation d'une synchronisation de plusieurs threads.
Le code est en C/C++, sous Linux (3.12).

Une dizaine de threads, répartis sur plusieurs cœurs CPU, doivent traiter des données en provenance d'autres threads.
Plusieurs threads peuvent attendre les même données d'un même thread et doivent tous être réveillés en même temps (non strict).
Un thread peut parfois prendre plus d'un cycle pour traiter les données, l’événement doit donc être "bufferisé" afin de ne pas mettre le thread en question en sommeil au prochain cycle.
Le mécanisme doit être compatible avec epoll.

A première vue, quand j'ai spécifié l'architecture, je pensais que Linux disposait nativement d'une primitive compatible avec mon besoin.
Malheureusement, depuis hier, je sèche. La plupart des solutions existantes sont conçues pour ne fonctionner qu'avec un seul thread consommateur (ou limité à un seul thread pouvant être réveillé).

Voilà, vous savez tout, j'espère que vous serez plus imaginatif que moi

Merci !

EDIT: j'aimerai bien sûr éviter d'envoyer un événement différent à chaque thread en attente. Le producteur ne doit pas avoir connaissance du nombre de consommateur.

[smarlytomtom]

Bonjour Marloon !

Tes threads sont-ils en attente passive ou active ?
Quelle était ton idée de base pour l'échange des données entre tes threads ?

[Marloon]

Bonjour,

le mécanisme doit s'intégrer dans une machine à états basée sur epoll, donc attente passive.
Le système doit traiter des images et des échantillons sonores; des threads produisent ces données, tandis que d'autres threads les consomment et les traitent. Les données (en mêmoire partagée) ne sont jamais modifiées par ces derniers.
J'ai donc tout simplement besoin d'un indicateur pour signaler que les données ont été mise à jour.

EDIT: Comme un encodeur audio qui encoderait en temps réel un flux PCM avec divers codecs en même temps (un par coeur CPU).

[smarlytomtom]

D'accord je connaissais pas du tout epoll, on en apprend vraiment tous les jours !

Si j'ai bien compris cette fonctionnalité te permet d'envoyer des events, de ce fait ne pourrais-tu pas émettre des événements en broadcast pour tous les abonnés et tu réalises une étape de traitement dans les threads qui détermine si c'est bien à lui que l'on parle ? Sans connaitre l'api c'est ce qui me paraîtrait le plus logique... ou alors tu peut mettre de côté l'étape de vérification si tu sais exactement quel thread doit être prévenu par quel thread en les abonnant à des events différents.

[Marloon]

Sans connaitre l'api c'est ce qui me paraîtrait le plus logique...

C'est justement cette API qu'il me manque

Il faudrait une sorte de eventfd, mais avec un compteur par descripteur ouvert. Le thread qui écrit mettant à jour tous les compteurs. Puis chaque thread en lecture décrémentant celui qui lui est propre. Mais sans avoir à gérer N descripteurs côté source.

[smarlytomtom]

Tel que tu le décrit je partirais sur l'utilisation de sémaphore qui ferait office de compteur (sémaphore non binaire) en plus de ceux que tu dois déjà utiliser pour tes ressources critiques. Ce mécanisme t'offre un compteur géré par le kernel

[Marloon]

Un compteur sémaphore ne me permet pas de savoir si la ressource a été mise à jour depuis la dernière lecture (contrairement à eventfd).
Et à quelle valeur initialiser ce sémaphore ? Sachant que l'on ne sait pas, quand la ressource est créée, combien de threads vont être en attente (et ils peuvent changer en cours d'exécution).

J'ai beau le tourner dans tous les sens, je vais être obligé d'utiliser un événement dédié par thread consommateur, et non par thread producteur. Ce qui est autrement plus complexe car je dois gérer moi-même l'enregistrement des clients et l'envoi des événements à chaque cycle, au lieu de laisser faire l'OS.

[smarlytomtom]

Je t'avoue ne pas voir de solution évidente... J’espère que quelqu'un de plus calé sur le sujet passera sur le post !