Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Partage de conteneur
Bonjour à tous,
J'ai lu que le conteneur Qqueue est ré-entrant et que c'est plus "fort" que safe-thread.
Deux threads différents partageant un pointeur vers un Qqueue peuvent-ils l'un faire des enqueue() et l'autre des dequeue() sans besoin d'utiliser une technique de synchronisation (mutex, sémaphore) ?
Salut,
Pour moi si tu as une Qqueue partager entre 2 threads tu dois protéger l’accès via de la synchro sinon tu risques d'avoir des problèmes.
Regarde ce lien ici.
Vous voulez participer aux Tutoriels, FAQ ou Traductions et faire partie de l'équipe Qt de Developpez.
N'hésitez pas à me contacter par MP.
Merci pour le lien, c'est plus clair.
Donc Qqueue est ré-entrant mais pas thread-safe.
Existe-il des conteneurs Qt qui soient thread-safe ?
Quel problème pourrai-t-on avoir, on accède jamais simultanément au même élément de la file ?
QUi t'as dit celaEnvoyé par DSGSLA
Un gros plantage ou erreur mémoire lors d'un push et pop par deux thread différent.
Que cherche tu as faire?
Je veux envoyer (unidirectionnel) des Qvariant (donc de taille variable) d'un thread à un autre.
Pourquoi ne pas utiliser les signal/slot?
Parce que le type de classes thread et leur nombre est variable. Je ne peut les déterminer qu'à l'exécution. Comment effectuer les connect dans ce cas ?Pourquoi ne pas utiliser les signal/slot?
De plus les threads peuvent être chaînés, comment synchroniser les flux entrants et sortant ainsi que les calculs à faire ?
peut tu expliquer un peu le problème.
Peut être que qreadwritelock peut t'aider
http://qt.developpez.com/doc/latest/qreadwritelock.html
Connais tu QtConcurrent?
Je vais essayer de présenter l'architecture de l'application.
Le programme est lancé avec un grand nombre de paramètres. A partir de ceux-ci il détermine un graphe dont les nœuds sont des threads variés. Les branches sont orientées (unidirectionnelles) et sont des tunnels de données de longueur variables. Les nœuds sont donc producteurs ou consommateurs ou producteurs et consommateurs.
Ok.
As tu regardé ces exemples?
http://qt.developpez.com/doc/latest/...emaphores.html
http://qt.developpez.com/doc/latest/...onditions.html
Unn truc qui pourrai être intéressant :
* Chaque noeud est un QObject qui :
- stock ce qu'il va consommer
- reçois les données à consommer par un slot
- envoyé les données produite par un signal
* chaque QObject est associé à un QThread qui lance une eventloop
Ainsi chaque branch correspond à une connexion.
Mais à chaque emit reçu je sors de ma boucle de traitement, non ?
Et comment faire les connect ?
Autrement un QVector peut-il être lu et écrit en même temps ? Tant que l'on accède à un occurrence qui existe.
pourquoi?Mais à chaque emit reçu je sors de ma boucle de traitement, non ?
quand tu créé ton graph, tu peut creer tes connect entre les noeud (QObject).Et comment faire les connect ?
Un autre avantage ( si c'est cohérent à ton besoin) c'est que tu pourra mettre plusieurs noeud dans un même thread et éviter de creer trop de thread.
oui et non.
S'il la taille tu vecteur ne change pas tu peux y accéder en Parallèle en lecture. Si sur une même occurrent un thread la modifie et un autre la li, il faut protéger.
Le QReadWriteLock peut t'aider si plusieurs threads accèdent au données en lecture.
Justement, si le consommateur connaît la dernière occurrence "autorisée" il peut lire pendant que le producteur rajoute de nouvelles occurrences. Non ?oui et non.
S'il la taille tu vecteur ne change pas tu peux y accéder en Parallèle en lecture. Si sur une même occurrent un thread la modifie et un autre la li, il faut protéger.
Si je suis dans une boucle de calculs sur les données déjà lues, à chaque fois qu'un signal du producteur est reçu la fonction SLOT prends la main. Et que se passe-t-il après ?pourquoi?Mais à chaque emit reçu je sors de ma boucle de traitement, non ?
Si le rajout modifie la taille du vecteur, il risque d’avoir réallocation et ton thread qui consomme risque de manipuler un truc qui est détruit => erreur mémoire
Le slot ne sera exécuté uniquement lorsque l'eventloop du thread le peux. Pour que cela marche, il faut que ton algo exploite l'eventloop à chaque Noeud.
Je ne comprends pas, désolé. Je ne connais pas la notion d'eventloop.Le slot ne sera exécuté uniquement lorsque l'eventloop du thread le peux. Pour que cela marche, il faut que ton algo exploite l'eventloop à chaque Noeud.
http://qt.developpez.com/doc/latest/...ndfilters.html
Les signaux sont fonctionnent sur la même base que les events ?
Je ne vois pas comment gérer les signaux en même temps que la boucle de traitement des données.
Quand tu connecte un signal et un slot entre deux QObject appartenant à deux QThread différent, l'eventloop est utilisé pour que le slot soit exécuté dans le bon thread.
C'était un proposition, mais si ce que font tes noeud n'est pas compatible avec l'utilisation d'une event loop, cela n'ira pas.
Il te reste donc à protéger les accès à tes QVector.
Merci pour tes réponses.
Je vais commencer un proto.
Je clos donc le fil.
Répondre avec citation
Partager