Gestion d'un thread graphique dans un programme utilisant OpenMP

Question

J'ai un programme C++ qui effectue un long calcul en parallèle en utilisant OpenMP. Maintenant, ce programme doit également répondre à l'entrée de l'utilisateur et mettre à jour certains graphiques. Jusqu'à présent, j'ai commencé mes calculs à partir du thread principal/interface graphique, en équilibrant soigneusement la charge de travail de sorte qu'il ne soit pas trop court pour masquer le temps de threading OpenMP ni trop long pour que l'interface graphique ne réponde plus.

De toute évidence, je voudrais résoudre ce problème en exécutant tout simultanément. Pour autant que je sache, OpenMP 2.5 ne fournit pas un bon mécanisme pour cela. Je suppose que ce n'était pas prévu pour ce type de problème. Je ne voudrais pas non plus dédier un noyau entier au thread de l'interface graphique, il a juste besoin de < 10% d'un pour son travail. Je pensais que peut-être séparer le calcul en un pthread séparé qui lance les constructions parallèles serait un bon moyen de résoudre ce problème. J'ai codé cela, mais OpenMP s'est écrasé lorsqu'il a été appelé à partir de pthread, similaire à ce bogue: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36242. Notez que je n'essayais pas de lancer des constructions parallèles à partir de plus d'un thread à la fois, OpenMP n'était utilisé que dans un pthread à travers le programme.

Il semble que je ne puisse ni utiliser OpenMP pour planifier mon travail GUI en même temps, ni utiliser pthreads pour que les constructions parallèles soient exécutées simultanément. Je pensais simplement gérer mon travail GUI dans un fil séparé, mais cela se révèle plutôt moche dans mon cas et pourrait ne pas fonctionner en raison des différentes bibliothèques que j'utilise.

Quelle est la solution du manuel ici? Je suis sûr que d'autres ont utilisé OpenMP dans un programme qui doit gérer simultanément une interface graphique/réseau, etc., mais je n'ai pas été en mesure de trouver des informations en utilisant Google ou le forum OpenMP.

Merci!

Answer 1

Il n'y a pas de solution de manuel. L'application de manuels pour OpenMP est des programmes non interactifs qui lisent les fichiers d'entrée, font de lourds calculs et écrivent des fichiers de sortie, tous en utilisant le même pool de threads de taille ~ #CPUs dans votre supercalculateur. Il n'a pas été conçu pour l'exécution simultanée de code interactif et de calcul et je ne pense pas que l'interopérabilité avec une librairie de threads soit garantie par la spécification. En dehors de la théorie, il semble que vous ayez rencontré un bug dans l'implémentation GCC d'OpenMP. Veuillez déposer un rapport de bogue auprès des responsables GCC et, pour l'instant, recherchez un autre compilateur ou exécutez votre code GUI dans un processus séparé, en communiquant avec le programme OpenMP via un mécanisme IPC. (Par exemple, E/S asynchrones sur des sockets.)