Main thread qui bloque un autre thread

Bonsoir,

Cela fait quelques temps que je réfléchis à un problème auquel je ne trouve pas la réponse, je viens donc vers vous pour cela. J'expose le problème :
Soient deux threads, le thread A et le thread B. Le thread A correspond au main thread de l'application, le thread B correspond à un thread des plus communs. Avant d'effectuer une longue boucle, le thread A lance le thread B qui doit effectuer des opérations pendant toute la durée d'exécution de la boucle dont il est question. Or, le thread A ne va logiquement pas laisser le thread B agir, utilisant la totalité des ressources dont l'application peut bénéficier, on aura donc une ligne d'exécution en fonction du temps comme celle-ci :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

A Appel ---- B | | | X | X | X | X | X | X | X | X Fin | | | | | | | | Fin

---

Avec la ligne des | = exécution, et la ligne des X = thread en attente.
Ce que je souhaiterais avoir est ceci :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

A Appel ---- B | | | | | | | | | | | | | | | | | | Fin Fin

---

Pour éviter que le thread A bloque le thread B durant la grosse boucle, j'ai pensé à tenter de lui baisser sa priorité :

Code:

---

QThread::currentThread()->setPriority(QThread::IdlePriority);

---

Sans effet notable, le thread A bloque toujours le thread B.
J'ai tenté pas mal d'autres choses, sans succès non plus. Bref, si vous avez une idée, si vous manquez d'informations ou autre, n'hésitez pas à poster !

Merci d'avance,
Amnell.

Salut.
Il faudrait un peu de code.
C'est bizarre ton problème.
Comment lance tu le Thread B?

Le thread B est bien lancé, j'ai vérifié. Je le lance avec start().

Code:

---

1 2 3 4 5 6

boucle { B->start(); for(...) { ... } // Cette boucle prend un certain temps à être taitée B->setState(false); }

---

Le thread lui-même :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

void run() { hasToContinue = true; forever { emit doSomething(); if(!hasToContinue) { emit finished(); return; } } } void setState(bool state) { hasToContinue = state; }

---

Le signal doSomething() n'est reçu qu'après la fin de la boucle, et toute opération sur le QCoreApplication est reportée, d'où ma théorie selon quoi le thread A bloquerait le thread B, ou du moins ne lui laisserait pas de quoi agir.

Citation:

---

Envoyé par Amnell

Le signal doSomething() n'est reçu qu'après la fin de la boucle,

---

faux

Citation:

---

Envoyé par Amnell

et toute opération sur le QCoreApplication est reportée,

---

vrai



Pourquoi?
je suis quasiment sur que ta boucle bloque l'eventloop. Et donc ses event s'accumule et sont exécuté qu'à la fin.

Dans ton cas :
Thread A : exécute une eventloop.
Thread B : emet des signaux

Tu connect un slot d'un objet du thread A au signaux du Thread B.

Dans ce cas la connexion est indirectement (Cela permet de faire des connect thread safe). Lors de l'émit du signal, un event est ajouté à l'eventloop du thread A pour être exécuté par celle çi. Et comme ton eventloop est bloquée, ce n'est qu'un fois que l'eventloop est débloquée que tes slots s'exécutent.

Citation:

---

je suis quasiment sur que ta boucle bloque l'eventloop. Et donc ses event s'accumule et sont exécuté qu'à la fin.

---

Exact. J'explique plus en détail le problème :
Le thread B a pour objectif d'envoyer un signal, connecté a un slot, pendant tout la durée de la boucle. Ce slot, du thread A, va avoir pour fonction de changer la valeur d'un booléen. Durant la boucle, on contrôle la valeur du booléen pour appeler QCoreApplication::processEvents(). De là, on peut penser que l'utilité d'un thread pour cela est minime. A la base, j'utilise un msleep sur le thread B. L'objectif est en réalité d'éviter d'appeler appeler QCoreApplication::processEvents() en permanence.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

boucle() { B->start() for(...) { // ... // Contrôle du booléen QCoreApplication::processEvents() si le booléen est à true // ... } B->setState(false); }

---

pourquoi tu ne met pas ta boucle for dans un thread?

J'y avais songé. Comme il n'y a apparemment pas d'autres solutions, je vais faire comme ça.
Merci encore, résolu.