Quand les objets stream C++ utilisent-ils des mutex?

Question

Dans la réponse à cette question Ovanes déclare:

S'il vous plaît être conscient que boost :: lexical_cast est beaucoup plus lent que atoi. Je l'utilise aussi très souvent dans un code non critique de performance . Le problème avec lexical_cast est qu'il utilise stringstream pour la conversion. Si vous travaillez dans un environement multi-thread une classe de flux de la lib norme utilisera les verrous sur un mutex pour chaque caractère inséré, même si l'objet de flux est utilisé à partir un seul numéro de thread.Your composé de 17 caractères impliquera 17 mutex verrouillés lorsqu'il est mis en flux. - Ovanes 22 juin à 11:59

Ce qui pose la question, quand est-ce des objets <iostream> verrouiller un mutex? Est-ce vrai pour les objets de <sstream>? Si oui, cela peut-il être évité?

Answer 1

Le standard C++ actuel (C++ 03) ne contient rien à propos du multi-thread. Pour cette raison, la façon dont une bibliothèque utilise les mutex dépend de l'implémentation spécifique.

Answer 2

Le problème avec string_stream est qu'il est assez lourd. Et ce n'est pas lié aux mutexes.

Et je vais vous expliquer pourquoi:

• stringstream utilise l'interface générique pour accéder tampon sous-jacente, identique à celui utilisé pour les fichiers ou pour accéder à la console: un ensemble de fonctions virtuelles. Il est plus lent et itère plus char *
• il Utilise des informations de paramètres régionaux afin que vous puissiez réellement analyser une chaîne qui dépend du type de séparateurs de milliers ou de différents types de chiffres qui sont récupérés pour une autre classe dans l'interface locale.
• Enfin, il appelle atoi pour convertir la chaîne en nombre.

lexical_cast est très puissant car il permet de jeter une valeur et non uniquement des nombres entiers comme on le fait avec atoi mais avec le pouvoir vient des prix. Deuxièmement, je ne pense pas qu'une implémentation string_buffer utilise des mutex. Le flux de fichier a un sens mais pas un flux de chaîne.