QWaitCondition sans QMutex ?

Pour l'acquisition je peux pas, les fonctions du SDK de la carte PCI sont en boucle infinie...
De plus je vois mal comment attribuer plusieurs QObject à un seul QThread, plutôt comment jongler entre les QObject pour qu'ils soient tous utilisables en même temps.

Citation:

---

Envoyé par alexgille

Pour l'acquisition je peux pas, les fonctions du SDK de la carte PCI sont en boucle infinie...

---

Tu peux utilise startTimer et la focntion voidtimerEVent(...) pour simuler la boucle infinie.

Citation:

---

Envoyé par alexgille

De plus je vois mal comment attribuer plusieurs QObject à un seul QThread, plutôt comment jongler entre les QObject pour qu'ils soient tous utilisables en même temps.

---

C'est levent loop qui permet de partager la thread.
Il faut bien comprendre que le thread ne s'exécute par réellement en parallèle mais elle partage les ressources CPU. Et ca peux devenir très casse tête si on ne fait pas attention . Par exemple un thread peux se retrouver à monopoliser tous le CPU et les autre thread attende indéfiniment.

Sauf que là, si mon second thread est occupé avec le QObject d'analyse, le traitement de la file d'attente ne se fera pas, vu que le thread est occupé .. je me trompe ?

Normalement il n'est pas possible qu'un thread monopolise le CPU si il a une priorité normal parce que le CPU attribut des quantum de temps définis aux processus .. je me trompe encore ?

Merci pour ton aide

Citation:

---

Envoyé par alexgille

Sauf que là, si mon second thread est occupé avec le QObject d'analyse, le traitement de la file d'attente ne se fera pas, vu que le thread est occupé .. je me trompe ?

---

Disons que le QThread ne peux exécuter qu'un slot à la fois. Vue tes explications tes QObject font des actions assez courte lorsqu'un signal est emit. Il devrais donc pouvoir facilement se partager un QThread. SI ca te semble plus simple commence par un QThread par QObject.

Citation:

---

Normalement il n'est pas possible qu'un thread monopolise le CPU si il a une priorité normal parce que le CPU attribut des quantum de temps définis aux processus .. je me trompe encore ?

---

créé un thread qui exécute

Code:

---

while(1);

---

et tu verra ce qui se passe ;)

Quand un signal est emis et que ton slot est dans un autre thread il se passe ceci :
1- copie des paramètres
2- ajout d'un event dans l'eventloop du thread pour éxécuter le slot.

A ce moment là mon QThread va contenir l'algo à exécuter et le QObject les signaux/slots utiles pour le QThread exécuté c'est ça ?

Mais comment faire pour faire cohabiter 2 algorithmes différent et différentes données dans un même QThread ? L'algorithme doit être placé dans le QObject ?

Une fois le QObject lié au QThread, comment on fait appel aux différentes données ?

Citation:

---

Envoyé par alexgille

A ce moment là mon QThread va contenir l'algo à exécuter et le QObject les signaux/slots utiles pour le QThread exécuté c'est ça ?

---

Qthread ne contiens rien. Tu n'as même pas besoin de le speciaiser. Par défaut QThread exévute une eventloop.

Citation:

---

Mais comment faire pour faire cohabiter 2 algorithmes différent et différentes données dans un même QThread ? L'algorithme doit être placé dans le QObject ?

Une fois le QObject lié au QThread, comment on fait appel aux différentes données ?

---

Tout est définie dans tes QObject.
Pour la cohabitation, ca depend de ce que font tes algo et de ce qui ne doit pas être bloqué.

Je vois où tu veux en venir, j'ai juste à exécuter la méthode de mon QObject dans l'eventloop du QThread.

Les signaux sont-ils queués ? Si c'est le cas ça résout mon problème car tant que le signal est interprété par le thread de stockage puis envoyé au thread d'analyse, que ce soit en direct, ou en différé via une FIFO ça effectue le travail demandé ...

Pour mettre 2 objets dans le même QThread je fais 2 moveToThread consécutif ?

Citation:

---

Envoyé par alexgille

Je vois où tu veux en venir, j'ai juste à exécuter la méthode de mon QObject dans l'eventloop du QThread.

Les signaux sont-ils queués ? Si c'est le cas ça résout mon problème car tant que le signal est interprété par le thread de stockage puis envoyé au thread d'analyse, que ce soit en direct, ou en différé via une FIFO ça effectue le travail demandé ...

---

dans notre cas oui.

Citation:

---

Envoyé par alexgille

Pour mettre 2 objets dans le même QThread je fais 2 moveToThread consécutif ?

---

sur chaque QObject

Dans le cas où les deux QObject dans le QThread n'aurait rien à faire, que ce passe-t-il ?

Dans mon cas, il faut alors que mes fonctions d'analyse et de stockage soient appelées directement dans le slot ?

Citation:

---

Envoyé par alexgille

Dans le cas où les deux QObject dans le QThread n'aurait rien à faire, que ce passe-t-il ?

---

l'eventloop se met en attente.

Citation:

---

Dans mon cas, il faut alors que mes fonctions d'analyse et de stockage soient appelées directement dans le slot ?

---

je pense oui.

Ok merci !

Me revoilà avec quelques questions :)

J'ai deux thread comme ceci:

Code:

---

1 2 3 4 5 6 7

class BufferStore : public QThread { signals: doJob(Pulse*); public slots: valuesReturned(Pulse*); storeRawValues(f64*); }

---

Code:

---

1 2 3 4 5 6 7 8

class PulseFinder : public QThread { public: run();//pour l'instant msleep(100); signals: done(Pulse*); public slots: giveMeAJob(Pulse*); }

---

Mon objet qui fait le va et vient entre les thread:

Code:

---

1 2 3 4

class Pulse { f64 * buffer; void savePart(); }

---

Et les connexions entres les QThread:

Code:

---

1 2 3 4

acquisitionThread::toBufferStore(f64*) <--> BufferStore::storeRawValues(f64*) BufferStore::doJob(Pulse*) <--> PulseFinder::giveMeAJob(Pulse*) PulseFinder::done(Pulse*) <--> BufferStore::valuesReturned(Pulse*)

---

Lorsque je stress un peu mon programme j'arrive à un problème ..
Le Pulse* envoyé à partir de BufferStore va bien dans PulseFinder et revient bien vers BufferStore en suivant le trajet des signaux que j'ai créé.
Le problème réside dans le fait que, une fois que PulseFinder renvoi à BufferStore le Pulse* et que BufferStore appel savePart() sur l'objet Pulse (dans le slot), il y a des fois (souvent) où le fichier n'est pas enregistré sur le disque.
On dirait que l'appel à savePart() est fait, mais que le thread stop son exécution faute de temps, ou à cause d'un nouvel appel du slot .. je ne sais pas.

Compte tenu du faite que je sois obligé de passer par des QObject que j'assignerai tous les deux dans un même QThread afin que les signaux/slots soient exécutés correctement et sachant que mon PulseFinder a une fonction à exécuter, comment puis-je faire pour que l'eventloop du QThread dans lequel vivra les 2 QObject BufferStore et PulseFinder (qui sont actuellement QThread) exécute la fonction du PulseFinder, les signaux et les fonctions appelées par les signaux, à intervalle régulier sans perte ?

Merci !

Citation:

---

On dirait que l'appel à savePart() est fait, mais que le thread stop son exécution faute de temps, ou à cause d'un nouvel appel du slot .. je ne sais pas.

---

Il n'y as aucune raison pour le thread se stop faute de temps ou auter.

Pour ton problème de sauvegarde, sans code, difficile de t'aider.

Code:

---

à intervalle régulier

---

C'est à dire?

Code:

---

1 2 3 4

<div class="bbcode_container"> <div class="bbcode_description">Code:</div> <hr /><code class="bbcode_code">à intervalle régulier</code><hr /> </div>C'est à dire?

---

Un système attribut des quantum de temps à ses processus et donc aux thread de mon programme.
Vu que là, dans mon thread, j'aurai deux QObject avec chacun son lot de petites fonctions à exécuter, l'eventloop du QThread dans lequel vivra ces 2 QObject fera l'attribution de quantum aussi ? Sinon qu'est-ce qu'elle fera ?
En faite je cherche à savoir comment manipuler l'eventloop afin que les signaux soient bien interprétés et surtout que mon PulseFinder puisse exécuter sa fonction d'analyse lorsqu'il le faut.

Pour le problème des fichiers j'ai trouvé la solution (je crois). Comme j'enregistre les fichiers avec en nom la date et l'heure, si deux fichiers sont enregistrés dans la même seconde, l'un écrase l'autre .. c'est tout bête.

Je n'ai rien compris... :aie:

Pourquoi l'eventloop devrais faire disparaître l'appel à certain slot??

On va faire plus simple xD

Avant:

Moi avoir 2 QThread.
Chaque QThread avoir slots qui font appels à des fonctions sur des Objets (de ma propre création :) ).
Chaque QThread avoir run() et exécuter son propre run() avec algo de traitement dedans x).
Paske moi vouloir faire exécution parallèle !

Après passage de l'homme sage (toi :p) sur mon code:

Moi avoir 2 QObject à la place et plus qu'un seul QThread ! :calim2:
Moi pas savoir comment faire pour mettre 2 QObject dans seul QThread en utilisant eventloop !
Moi pas savoir comment demander à seul QThread d'exécuter ce qui était AVANT dans les run() des deux QThread :o

Tarzan aime banane !

C'est un peu plus claire ^^

Citation:

---

Envoyé par alexgille

Moi pas savoir comment faire pour mettre 2 QObject dans seul QThread en utilisant eventloop !

---

Ben c'est moveToThread

Citation:

---

Envoyé par alexgille

Moi pas savoir comment demander à seul QThread d'exécuter ce qui était AVANT dans les run() des deux QThread

---

Ton "run" deviens ton slot, c'est tous ;)

Si ton slot et ton signal sont dans 2 thread différent, l’exécution du slot utilisera l'eventloop pour s'exécuter dans le bon thread. Tu n'as rien à faire de plus qu'un connect.

Tu pourra voir après si tu as besoin d'ajouter d'autre QThread pour équilibrer ce que tu appel "exécution parallèle".

Autre question..

Ma fifo dans mon thread de stockage doit-elle être Mutexée ?

Je pose cette question car je ne sais pas si le slot qui envoi le pointeur en tête de file et le slot qui reçoit les données traitées peuvent s'exécuter quasi simultanément et provoquer un accès concurrent.

Merci :ccool:

Citation:

---

Envoyé par alexgille

Autre question..

Ma fifo dans mon thread de stockage doit-elle être Mutexée ?

Je pose cette question car je ne sais pas si le slot qui envoi le pointeur en tête de file et le slot qui reçoit les données traitées peuvent s'exécuter quasi simultanément et provoquer un accès concurrent.

Merci :ccool:

---

Comme cela, je dirai qu'il y as un risque et donc oui il faut protéger.

Si tu émet ta donnée, y as t'il une raison d'avoir la FIFO?

Oui parce que la quantité de travail est variable et le thread de stockage peut se remplir plus vite qu'il ne se vide en émettant vers le thread d'analyse.