Singleton et multithreading

Salut,

Après une recherche sur le forum, sans succès, je viens donc vous poser ma petite question.

Le contexte :
Je vais développer un serveur. Je pensais à faire un thread par client, sachant qu'il n'y aura qu'entre 2 et 8 clients environ.
Alors les clients intéragiront avec le serveur, et enverront des commandes qui entraineront que mon serveur modifiera une variable chez lui. Cette variable est un singleton.
Or, comme les intéractions risquent d'être fréquentes(en effet, je pense environ à 2 requêtes par client par seconde, et ce pendant qqlq minutes(je prends de la marge), les mutex seraient probablement trop couteux et ralentiraient le tout, ce qui annulerait l'intérêt d'utiliser les thread ... ca reviendrait presque à traiter les clients itérativement dans un while, du point de vue lenteur.
Alors, ma question est :
Sachant que je vais probablement utiliser la méthode du double-check pour l'instanciation, je ne sais pas cependant comment faire pour que, lorsqu'un thread modifie la variable singleton, un autre ne la modifie pas en meme temps, ou presque, ce qui entrainerait un problème du genre une seule modification faite sur les 2 demandées, etc ... ?

Merci d'avance :D

Pour la récupération du singleton, le double-check est pratique, mais pas encore l'ultime. Pour la modification du singleton, ce n'est pas ce système qui te protègera, c'est à toi de protéger les routines critiques.

Comment les protéger, sans mutex? :aie:

Avec des sections critiques, c'est plus léger, ou parfois des opérations atomiques si le compilateur y donne accès.

Pour les sections critiques j'ai vu que l'api WIN32 fournit des fonctions.
Cependant, en vue d'une portabilité(au moins Windows/Unix), j'aimerais savoir s'il y a des libs qui fournissent ceci en "portable"?
Boost::thread fournit des outils pour des sections critiques ou opérations atomiques?
A propos, que sont les opérations atomiques et comment les réaliser?

Boost.Threads ne propose rien à ce niveau, elle est encore trop jeune, je pense, pour proposer suffisemment de fonctions pour le travail de tous les jours en multithreads.
Les opérations atomiques sont des opérations que le processeur exécute en une seule fois, par exemple incrémentation et test. S'il ne les propose pas, on ne peut pas en créer. Dans Qt, ils ont un header spécial pour ces choses - qatomic.h -

Et donc niveau librairies portables proposant ce qu'il faut pour créér des sections critiques, qu'est-ce qu'on trouve?(si ça existe)

Une question bête : les sections critiques, elles sont pas protégées avec des mutex ?

Très pertinente la question :oops: Aucune idée.

Citation:

---

Envoyé par Eusebe

Une question bête : les sections critiques, elles sont pas protégées avec des mutex ?

---

Non, ce sont des objets _normalement_ plus légers, du moins pour autant que je sache !
Des bibliothèques pour les sections critiques, je ne sais pas. Par exemple, je ne sais même pas si Linux en propose, je suppose que oui, mais je n'ai pas encore été confronté au fait.

Une section critique, c'est du pur windows, c'est comme un mutex en plus léger, mais ça ne permet pas de lock inter process.

Dans ton cas, une vingtaine de lock par seconde, je ne pense pas qu'il y ait de problèmes quelque soit la primitive de synchro utilisée.

Les mécanismes de "double check", je m'en méfie comme de la peste, la plupart ne fonctionnent pas...

Bon, ben pour les sections critiques, c'est résolu :lol:

Il doit y avoir quelque chose sur le sujet dans Loki.

Je viens d'aller voir Loki.
En effet, et ça utilise des mutex, et apparemment ce sont bien des mutex que je vais utiliser.
Ca suffira vous pensez? Après tout ca doit être bien fait les mutex... Pas si lent que ça.

Donc, pour clore le sujet, je pense que je vais utiliser Boost.Thread... Vous avez mieux? :mouarf:

C'est vrai que Loki propose des outils mieux adaptés pour les synchronisations !

Ah? en quoi ils sont mieux adaptés?
C'est plus léger et plus rapide?

La référence, en matière d'articles et plus, c'est ACE. Tu y trouveras tout ce dont tu as besoin pour faire du réseau TR de façon portable. C'est surtout que la partie réseau et la partie thread ont été conçues pour travailler main dans la main. La doc est un peu chaude, de même que les articles (qui sont ultra spécialisés), mais il existe un très bon tutoriel dont j'avais déjà donné l'adresse ici-même.
On peut critiquer le poids du bestio.

Quand au double check, il fonctionne mal et ne sert pour pour la création de ton objet.
Tu as plus vite fais d'avoir une fonction create(Params) dans ton singleton. fonction que tu appeleras dans le thread de démarrage de l'appli. Et une fonction instance() qui renvoie ton singleton. Après, suivant les besoins, tu peux avoir un mutex dans instance(), ou des mutex/locks qui distinguent les modes écrivains/lecteurs dans chacune des fonctions de ton singleton. A voir en fonction des rôles à remplir.

Ok, merci beaucoup à tous, ça devrait aller là :P