Discussion :

[ymoreau]

Bonjour,
Désolé de ce titre un peu vague. J'ai lu la doc (et le tuto de yan) sur les threads, mais jamais pratiqué. Je me demande ce qui est le plus simple dans mon cas :
J'ai un traitement à faire sur plusieurs fichiers, qui modifiera une classe au fur et à mesure de l'avancement, et lira/écrira des données dans une autre classe (interfaçant une base de données). Le traitement a ses propres données temporaires et peut être parallélisé, par contre l'accès aux autres classes non, leurs données sont partagées.
Je voudrais utiliser au maximum les capacités de la machine (potentiellement un serveur avec beaucoup de coeurs), et lancer autant de traitements en parallèle que possible.

QtConcurrent semble le plus simple à utiliser, pour gérer automatiquement le nombre de threads à créer etc. Mais je ne comprends pas bien comment créer une ressource commune.
Donc je me dis que ça n'est pas assez adaptable, et qu'il faut plutôt partir sur QThreadPool, créer mes classes de ressources avec QMutex, puis gérer les appels au mutex dans le traitement héritant de QRunnable.

Si quelqu'un avec de l'expérience pouvait brièvement m'indiquer la meilleure voie à suivre, je saurais dans quelle direction me lancer ^^
merci d'avance !

[yan]

Salut

J'ai un traitement à faire sur plusieurs fichiers, qui modifiera une classe au fur et à mesure de l'avancement, et lira/écrira des données dans une autre classe (interfaçant une base de données). Le traitement a ses propres données temporaires et peut être parallélisé, par contre l'accès aux autres classes non, leurs données sont partagées

Peut être créer un QObject par module de traitement et les répartir entre plusieur QThread? Ainsi la communication se fera par les Signal/Slot. Et tu pourra répartir les charges entre différent QThread (et ainsi limiter le nombre de thread).

Ton problème ressemble à un problème de producteur/commateur :
http://qt-project.org/doc/qt-4.8/thr...emaphores.html
http://qt-project.org/doc/qt-4.8/thr...onditions.html

Je voudrais utiliser au maximum les capacités de la machine (potentiellement un serveur avec beaucoup de coeurs), et lancer autant de traitements en parallèle que possible.

Ca va dépendre de ce que tu entend par parallèle.
Si ce sont de petit traitement, tu peut généralement les regrouper dans un même thread.
Si se sont de gros traitement, un nombre de thread au dessus du nombre de coeurs ralentira certainement tous les traitements parallèle.

[ymoreau]

Merci de ta réponse !
En fait il n'y qu'un (potentiellement gros) traitement qui travaille sur un fichier, il ne peut pas être subdivisé. Par contre, je dois traiter beaucoup de fichiers et j'aimerais dupliquer le traitement sur plusieurs threads où chaque instance s'occuperait de son propre fichier.
Donc si j'ai bien compris, il n'y a que des producteurs qui ne dépendent pas les uns des autres, mais qui ont besoin de ces ressources communes (totalement indépendantes de l'état du traitement). En pratique lire des infos dans un tampon partagé, et rajouter quelques infos à ce tampon quand il y en a de nouvelles. Pour le reste chaque instance de traitement lit son propre fichier, et écrit ses propre données de résultat.

Et je comptais justement créer autant de threads que de coeurs disponibles (moins un pour la boucle principale d'évènements).

[yan]

Par contre, je dois traiter beaucoup de fichiers et j'aimerais dupliquer le traitement sur plusieurs threads où chaque instance s'occuperait de son propre fichier.

C'est à dire?

[ymoreau]

Disons une fonction prenant un nom de fichier en argument, créant des données temporaires avec le contenu du fichier, puis envoyant tout ça dans une base de données. On peut appeler cette fonction plusieurs fois en parallèle avec à chaque fois un des fichiers de la liste à traiter, puisque les données d'entrée et les données sortantes sont propre à chaque fichier.
Sauf que ce traitement va aussi avoir besoin de données communes à tous les fichiers, en lecture et parfois en écriture.

Donc en gros, j'aurais une ressource commune avec un mutex, et plusieurs instances de la fonction de traitement.

[yan]

Pour la lecture des fichiers, c'est surtout l’accès du fichier qui va prendre du temps. Donc tu ne va pas pouvoir beaucoup (et se sera surement le contraire) accélérer la lecture en utilisant plusieurs thread.

Si j'ai bien compris, tu as un module qui ne fait que lire un fichier pour récupéré des données et un module qui exploite les données lue.
C'est bien cela?


pourquoi?

données communes à tous les fichiers

En alternative au mutex, regarde les readwritelock
http://qt-project.org/doc/qt-4.8/qreadwritelock.html

Et au lieu d'utiliser les mutex directement regarde :
http://qt-project.org/doc/qt-4.8/qmutexlocker.html
http://qt-project.org/doc/qt-4.8/qreadlocker.html
http://qt-project.org/doc/qt-4.8/qwritelocker.html

[ymoreau]

A vrai dire la lecture des données se fait en même temps que le traitement, du XML en méthode SAX, donc il y a lecture sur disque puis traitement, lecture sur disque puis traitement (et le traitement n'est pas négligeable comparé à la lecture), donc si le disque peut être lu en continu pendant que les threads ayant déjà des données en mémoire sont au boulot et ainsi de suite, je devrais accélérer l'ensemble.

Pour le mutex je parlais de façon générale, je regarderai quelle classe est la mieux adaptée, mais là c'est surtout l'architecture générale que j'ai du mal à penser.

[yan]

A vrai dire la lecture des données se fait en même temps que le traitement, du XML en méthode SAX, donc il y a lecture sur disque puis traitement, lecture sur disque puis traitement (et le traitement n'est pas négligeable comparé à la lecture), donc si le disque peut être lu en continu pendant que les threads ayant déjà des données en mémoire sont au boulot et ainsi de suite, je devrais accélérer l'ensemble.

Pour le mutex je parlais de façon générale, je regarderai quelle classe est la mieux adaptée, mais là c'est surtout l'architecture générale que j'ai du mal à penser.

L'ordre de lecture des fichiers est il important?

[ymoreau]

Non. J'ai une liste de fichiers à traiter, je peux distribuer ça dans mes threads n'importe comment

[yan]

Non. J'ai une liste de fichiers à traiter, je peux distribuer ça dans mes threads n'importe comment

Si le thread de traitement sur un fichier lue est plus long que la lecture.
Pourquoi ne pas juste utiliser deux thread?
1- lecture des fichier
2- traitement des données lue

[ymoreau]

Comme je le disais la lecture se fait au fur et à mesure, donc ça ne me parait pas bon de séparer les tâches dans ce sens. Et puis plus de 2 threads c'est pour aller plus vite, sur une machine à 16 coeurs l'idéal serait que le disque soit en lecture quasi permanente et que les traitements répartis derrière suivent la cadence.

[yan]

Comme je le disais la lecture se fait au fur et à mesure, donc ça ne me parait pas bon de séparer les tâches dans ce sens. Et puis plus de 2 threads c'est pour aller plus vite, sur une machine à 16 coeurs l'idéal serait que le disque soit en lecture quasi permanente

Si tu lit en parallèle sur le disque, c'est surtout le disque qui va te bloquer et non le nombre de thread. Donc, ça ne servira certainement à rien de faire 16 thread de lecture.

Pour reprendre l'histoire des QObject et QThread, tu pourrais :
1- un QObject par fichier - répartie sur N Thread. Tu pourra ainsi equilibrer les charge facilement
2- un QObject pour le traitement - sur 1 thread( le traitement ne peut être effectué en parallèle, c'est bien cela?)
3-Les appels au méthode se passe par le système de Signal/Slot => le slot s'éxécute dans le thread associé au QObject

La QR de la FAQ n'est pas terrible je devais la refaire . Regarde plutôt ces articles : http://qt-labs.developpez.com/#thread


Pour la Lecture des fichiers tu pourrais aussi imaginer l'utilisation d'un des algo QtConcurrent mais 16 thread qui lisent en parallèle me semble beaucoup trop. Ou alors tu as un disque dur utra rapide.

[ymoreau]

Oui bien sûr sauf que comme je le disais la lecture n'est qu'une partie du traitement. Imaginons que le traitement passe 30% de temps à lire le disque, 30% à traiter le texte et 30% à envoyer le résultat en base de données. Avec 3 threads qui liraient les uns à la suite des autres, le tout devrait aller 3 fois plus vite, puisque pendant les 60% restant un autre thread peut lire sur disque et ainsi de suite.

Et si, le traitement peut être effectué en parallèle, il a juste ponctuellement besoin d'une ressource partagée.
Quelque chose dans ce goût

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
Traitement T1           - Ressource R              - Traitement T2
T1 lit sur disque
T1 traite du texte                                   T2 lit sur disque
                        T1 lit une info dans R       T2 traite du texte
T1 traite du texte      T2 écrit une info dans R		
etc                                                  etc

[ymoreau]

Bon je vais partir sur du QMutex avec une QThreadPool qui gèrera les threads.

Donc mes classes partagées héritent de QMutex et seront utilisées au sein de l'utilisation d'un QMutexLocker par le traitement.

La classe effectuant le traitement hérite de QRunnable. J'en instancierai plusieurs qui seront lancé par une instance de QThreadPool. J'ai vu qu'on peut savoir combien de threads lancer pour la machine avec Thread::idealThreadCount().

La seule chose qui m'embête c'est que les instances de thread sont supprimées une fois leur tâche finie, or j'aurais plutôt besoin de boucler : une fois la tâche finie, la relancer avec un nouveau paramètre. Il me semble plus efficace de réinitialiser quelques structures de données dans l'objet effectuant le traitement plutôt que le supprimer et en allouer un nouveau.
Sinon je peux aussi distribuer dés le début toute ma liste de fichiers, et ça serait la classe de traitement qui gèrerait sa propre sous-liste. Mais bon il pourrait y avoir un thread qui termine avant les autres, ça ferait un coeur qui n'est plus utilisé.

Edit : sinon je viens de penser une structure de données partagée qui contient la liste de fichiers que chaque thread appelle (avec un mutex) chaque fois qu'il a terminé pour obtenir un nouveau fichier parmi ceux restant. Quand il n'y en a plus, il se termine.

[yan]

Donc mes classes partagées héritent de QMutex et seront utilisées au sein de l'utilisation d'un QMutexLocker par le traitement.

Hérite de QMutex???

La seule chose qui m'embête c'est que les instances de thread sont supprimées une fois leur tâche finie, or j'aurais plutôt besoin de boucler : une fois la tâche finie, la relancer avec un nouveau paramètre. Il me semble plus efficace de réinitialiser quelques structures de données dans l'objet effectuant le traitement plutôt que le supprimer et en allouer un nouveau.

http://doc.qt.nokia.com/4.7-snapshot...#setAutoDelete
Au lieu de faire des runnable, pourquoi ne pas utiliser un algo concurrent?
comme http://doc.qt.nokia.com/4.7-snapshot...ap.html#mapped

[ymoreau]

J'ai sans doute mal compris l'utilisation d'un mutex, je pensais qu'on appelait "lock/unlock" directement sur la ressource pour interdire aux autres threads d'y toucher. Je viens de voir un exemple où le QMutex est un membre statique de la classe contenant la ressource.

En fait je n'ai peut être pas bien saisi non plus comment fonctionne les algos de QtConcurrent, on leur donne une liste d'objets et une fonction à appeler sur chacun d'eux (en distribuant les appels). Dans les exemples la fonction appelée par concurrent est une simple fonction, moi j'aurais plutôt une classe qui doit être initialisée avec des références vers mes ressources partagées, plus quelques données membres et un traitement découpé en plusieurs fonctions.

[yan]

J'ai sans doute mal compris l'utilisation d'un mutex, je pensais qu'on appelait "lock/unlock" directement sur la ressource pour interdire aux autres threads d'y toucher. Je viens de voir un exemple où le QMutex est un membre statique de la classe contenant la ressource.

Pour qu'un mutex fonction il faut partager une même instance.

En fait je n'ai peut être pas bien saisi non plus comment fonctionne les algos de QtConcurrent, on leur donne une liste d'objets et une fonction à appeler sur chacun d'eux (en distribuant les appels). Dans les exemples la fonction appelée par concurrent est une simple fonction, moi j'aurais plutôt une classe qui doit être initialisée avec des références vers mes ressources partagées, plus quelques données membres et un traitement découpé en plusieurs fonctions.

Qt concurent accepte normalement les functor :
http://doc.qt.nokia.com/4.7-snapshot...mber-functions

Je n'ai pas testé mais il devrais aussi marcher avec les lambda.

[ymoreau]

En fait je pensais faire hériter ma classe de QMutex puis créer un QMutexLocker sur l'instance avant d'accéder à ses fonctions. Mais finalement j'ai mis un QMutex en membre de cette classe et je crée le QMutexLocker dans le bloc de chaque fonction qui sera appelée par les threads.

En effet on peut appeler des fonctions membre de classe. Cependant, la liste à traiter serait ma liste de fichiers, et pas une liste d'instances de la classe traitant le fichier (ça serait bien trop lourd).

[yan]

En effet on peut appeler des fonctions membre de classe. Cependant, la liste à traiter serait ma liste de fichiers, et pas une liste d'instances de la classe traitant le fichier (ça serait bien trop lourd).

Je me suis trompé de lien : http://doc.qt.nokia.com/4.7-snapshot...nction-objects

un functor c'est : http://cpp.developpez.com/faq/cpp/?page=STL#STL_functor

[ymoreau]

Ok, mais je ne vois pas comment adapter ça à mon besoin. Dans l'exemple on appelle une fonction de QImage, instance de la liste traitée par QtConcurrent. A quel endroit je spécifierais de créer une instance de ma classe puis d'appeler une certaine function avec l'élément de la liste traitée ? Et de toute façon, est-ce que du coup ça ne créerait pas une instance de ma classe de traitement à chaque tour de boucle ? Comme je l'ai dit ça serait bien trop lourd.
Je peux avoir plusieurs millions de fichiers à traiter, alors une allocation mémoire à chaque élément ferait perdre pas mal de temps je pense.

Il me semble plus simple de faire quelque chose comme ça non ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
QThreadPool threadpool;
QVector<Runnable*> threads;
for(int i=0; i<threadpool.maxThreadCount(); ++i)
    threads.append(new Runnable(donnees_partagees));
foreach(Runnable *r, threads)
    threadpool.tryStart(r);