Discussion :

[screetch]

Plop,

dans le cadre de mon projet j'ai réalisé un Task Manager qui marche très bien, qui est même très rapide parce qu'il a très peu de fonctionnalités.
En gros, on lui donne une tâche a faire, il la place dans une queue. Un thread disponible prend la tâche, soit l'éxécute si elle est atomique ou bien la coupe en deux morceaux plus petit, poste les deux morceaux et se rendort.

La synchronisation est très simple, c'est un simple sémaphore qui est incrémenté lorsqu'une täche est postée, et decrémentée lorsqu'une tâche est retirée (donc si il n'y a rien a faire, les threads dorment)
les taches sont dans une pile atomique () enfin une pile (et pas une queue malheureusement) ou ajouter et retirer sont des opérations atomiques.
Tout ca marche très bien et vu la simplicité du concept, c'est très efficace et il y a peu de synchro entre les threads, presque pas de blocage.
Il y a un thread par coeur sur la machine donc tout marche nickel.

Mais j'ai été confronté a un problème très ennuyeux récemment: sur windows (et sur mac surtout d'ailleurs) le thread principal est "spécial", il a la gestion de la souris/clavier, et donc toutes les commandes OpenGL/DirectX et toutes les opérations sur les fenêtres devraient s'effectuer sur ce thread.


Bon la ou j'ai été ennuyé au début c'est que le thread principal n'est même pas capable d'executer des tâches; il créait tous les autres threads, envoyait le premier job et se reposait (ce flemmard). Les autres jobs postent d'autres jobs postent d'autres jobs a leur tour, etc, perpétuant ainsi la chaîne de la vie.

Bon j'ai donc changé pour que le thread principal soit dans les threads "worker", maintenant j'en suis a un autre problème: comment dire q une tâche de s'executer sur un thread en particulier? Ce que j'ai fait pour l'instant c'est ajouter une enumeration Affinity { MainThread, DontCare };donc soit on s'execute sur le thread principal, soit on s'en fout.
Le problème c'est que le thread principal il branle rien (cte flemmard) en attendant une tâche spécialement pour lui; en effet, soit on est en affinité DontCare et on s'execute sur les threads 2, 3, 4..., soit on est en MainThread et on s'execute sur le thread principal. Du coup le trhead principal n'aide pas du tout a la parallelisation, lorsqu'il a rien a faire j'aimerai qu'il participe aux tâches ménagères aussi!
je me demande donc comment on peut faire de manière efficace une implémentation d'un task manager avec une affinité; avec un seul semaphore, comment on peut reveiller le bon thread? si on reveille un thread au pif, ca marche pas.
J'ai pensé a un truc, WaitForMultipleObjects, sur Windows, qui me permettrait d'écouter deux semaphores en meme temps, mais coomment faire sur macOS ou linux?

d'utres idées géniales?

[Médinoc]

Ah, donc tu cherches à faire un Thread Pool, en fait?

[JolyLoic]

Le plus simple n'est-il pas de faire un thread de plus qu'il n'y a de cœurs sur la machine, et de s'en moquer si le thread principal joue juste l'inspecteur des travaux finis ?

[screetch]

Oui, le thread pool est déjà fini, ce qui m'ennuie c'est que dans un cas bien précis (dont je ne peux pas me débarasser a cause des idiots de microsoft et apple) je dois effectuer des trucs sur un thread bien précis.

JolyLoic, oui c'est l'état actuel des choses mais j'aimerai m'assurer qu'il y a exactement n threads disponibles pour recevoir des tâches; sinon ce qui va se passer c'est que par moment j'aurai n+1 tâches en cours pour n coeurs, j'aurai préféré que ca n'arrive pas.

[stardeath]

Oui, le thread pool est déjà fini, ce qui m'ennuie c'est que dans un cas bien précis (dont je ne peux pas me débarasser a cause des idiots de microsoft et apple) je dois effectuer des trucs sur un thread bien précis.

c'est pas si idiot que ça, du coté de l'os, ça ne fait qu'une cible pour ennuyer les événements, et un "envoyeur" d'actions à contrôler, et de ton coté, ça t'assure que ces données sont correctes et que normalement il n'y aura pas un de tes threads qui mettra le boxon là dedans.

ensuite je crois que tu te créés un faux problème, à moins que ton soft n'a jamais à faire de communication, n'a jamais d'actions utilisateur à traiter ni d'interface graphique à rafraichir, il vaut mieux que tu te gardes un thread sous le coude pour moniter le tout, donc de n'utiliser que n-1 threads pour traiter ta tâche.

[screetch]

Je n'ai absolument pas besoin d'un thread pour regarder ce qui se passe; dans la version précédente, le thread principal s'endormait après avoir lancé la première tâche, et se réveillait a la fin du programme. Ca marchait très bien comme ca, ce thread est complétement inutile en soit... si ce n'est que le système d'exploitation a décidé que ce thread était spécial et qu'on me "force" a l'utiliser.

[stardeath]

au hasard, dans la fonction WndProc, jouer avec PeekMessage au lieu de GetMessage et comme la fonction ne sera plus bloquante, elle pourra brancher vers le traitement de la tâche.

[JolyLoic]

Je pense ne pas être d'accord avec toi.

Si tu as N procs, et N+1 threads, le pire que tu peux avoir est si tu fais beaucoup sur ton thread graphique (ce n'est normalement pas le cas, à ce que tu dis), alors les context switches vont au global légèrement ralentir les calculs.

Si tu as seulement N threads dont l'un partage des tâches graphiques et des tâches de calcul, il se peut que pendant un certain temps, ton IHM ne réponde plus, parce que tu fais un calcul long (=> pas de rafraîchissement, pas de prise en compte d'un click sur "annuler", voire l'OS qui pense que l'application est morte).

Je préfère le premier cas.