6ème partie (enfin! s'écrie mon public en délire), où j'évoque les tentations du multithreading, et laisse entendre qu'il faut mieux les laisser aux grands garçons (et aux grandes filles).
Ceux qui, comme votre serviteur, auront passé trop de temps sur les forums de développement de jeux vidéos (même stack overflow s'y met: regardez!) auront pu découvrir un certain nombre de questions qui peuvent se résumer ainsi: où est-ce que je met mes threads?
Le jeune scarabée s'empresse de lister alors une série de composants, et leur assigne unilatéralement un thread, histoire de dire que. L'on se retrouve avec un thread par zone, un thread pour la physique, un thread pour les communications, un thread pour le commerce, un thread pour le pathfinding, etc. Côté client, on imagine un thread pour le rendu, un thread pour la GUI, un thread pour la physique, un thread pour la musique, un thread pour les communications avec le serveur, und so weiter.
Arrêtez là, malheureux! Écoutez les paroles de celui qui s'est lamentablement planté avant vous sur exactement le même chemin.
Pas de threads. Nope. N'essayez pas, ce n'est même pas la peine. Non seulement ce n'est pas la peine, mais je soutiens qu'un effort non négligeable est nécessaire pour supprimer, ou du moins abstraire, tout ce qui pourrait avoir besoin d'un thread (mettons, le réseau).
La raison est tout simplement qu'il est horriblement compliqué de gérer la synchronisation des threads. Et qu'en plus, les bibliothèques externes sont rarement thread safe, et qu'il faut donc coder nombre de couches d'abstractions pour garantir que l'on ne va pas exploser en vol. Je ne parle même pas des test unitaires et du débuggage.
Du côté serveur, prévoyez également une simple boucle, éventuellement pilotée par les événements réseau. La bibliothèque boost::asio est particulièrement pratique pour ce cas de figure: elle autorise à faire tourner des routines basées sur un chronomètre d'une part, et sur les messages réseau d'autre part, mais toujours dans le même thread.
Enfin, pour ceux qui s'inquiètent de voir les trois quarts de leur puissance de calcul inutilisés, voici ce que vous pouvez en faire:
- Faire tourner plusieurs instances du serveur
- Calculer des statistiques à partir de la base de données
- Compiler du code pour ajouter des fonctionalités!
Quant à ceux qui se laissent tenter par le chant des sirènes, j'attends avec impatience vos retours d'expérience, statistiques à l'appui. Bon courage!
Aucun commentaire:
Enregistrer un commentaire