Oui, mais je me disais que peut-être que si une error survient, la socket plante tout simplement... Donc je n'étais pas sûr
Bien en fait tu te rappelles sûrement de mon projet. J'ai tout simplement stocké les clients dans un tableau 2d de liste :
std::list m_clients[32][18];
chaque parti du tableau représente une zone dans la carte. La carte (enfin une carte), c'est entièrement gérée par une machine physique.
C'est donc plusieurs threads qui accomplissent différentes tâches sur les clients qui y ont accès en même temps.
Writers threads : addClient et receivingData (uniquement si la socket est disconnected pour receiveingData. On supprime le client des lists. addClient et bien on bloque la liste pour en ajouter un)
Readers threads : processingData et updating (ces deux là ne font que lire les valeurs des joueurs et les modifier au besoin. Les variables sont séparés de façon à ce qu'ils n'utilisent pas les mêmes donc pas de lock)
Moi je me suis dit que ça serait bien que chaque thread se présente uniquement pour la zone qu'ils sont en train de lire ou écrire. Ainsi, tous les readers peuvent agir en même temps et on a un writer à la fois qui bloque uniquement la zone (les readers et même l'autre writer peuvent donc continuer de faire du traitement sur les autres zones de la carte pendant que le writer écrit dans une autre zone)
ça me donne donc des tableaux comme ça :
sf::Mutex m_lock_receivingData[32][18];
sf::Mutex m_lock_updating[32][18];
sf::Mutex m_lock_processingData[32][18];
sf::Mutex m_lock_receivedData;
addClient les bloque tous quand il écrit. recevingData se bloque en lecture (le premier donc) et bloque receivedData (qui est une liste des événements à traiter) s'il veut en ajouter un. les autres se bloque tout simplement lorsqu'ils sont en lecture. Il est par contre important de les bloquer dans un ordre identique pour les deux writers sinon ils pourraient s'inter-bloquer.
Donc en théorie, cette façon de faire est très optimisé. Par contre, en pratique, si ça consomme beaucoup... alors je ne sais pas trop quoi faire...
Quatre solutions :
-un à la fois sur la carte, mais là ça sert à rien d'avoir plusieurs threads.
-en sachant qu'une lecture est plus rapide qu'une écriture, on pourrait simplement utiliser un tableau et lorsqu'un writer veut écrire, il bloque la zone et lorsqu'un lecteur veut lire, il la bloque et la débloque aussitôt (pour permettre aux autres lecteurs de lire en parallèle).
-un seul tableau et peut importe qu'il s'agisse d'une lecture ou écriture, on bloque la zone.
-les variables comme en haut, mais pas en tableau. Par contre, il faudrait attendre qu'un thread en écriture ait fait le tour de la carte entière avant de pouvoir recommencer à lire... pas super...
J'espère que tu as une meilleure idée ou un simple conseil à me donner (par exemple qu'une des solutions s'avère plus rapide que ce que je prévoyais faire ou encore que la solution la plus rapide se situe dans mes choix ou dans ta tête
)
merci et bonne journée !
