Toujours déclarer std:: mutex comme mutable en C++11?

Non. Cependant, la plupart du temps ils seront.

Bien qu'il soit utile de considérer const comme "thread-safe" et mutable comme "(déjà) thread-safe", const est toujours fondamentalement lié à la notion de promesse "Je ne changerai pas cette valeur". Il le sera toujours.

J'ai une longue pensée, alors supportez - moi.

Dans ma propre programmation, je mets const partout. Si j'ai une valeur, c'est une mauvaise chose de la changer à moins que je dise que je le veux. Si vous essayez de modifier délibérément un objet const, vous obtenez une erreur de compilation (facile à réparer et aucun résultat expédiable!). Si vous modifiez accidentellement un objet non-const, vous obtenez une erreur de programmation d'exécution, un bug dans une application compilée et un mal de tête. Il est donc préférable de se tromper sur le premier côté et de garder les choses const.

Par exemple:

bool is_even(const unsigned x)
{
    return (x % 2) == 0;
}

bool is_prime(const unsigned x)
{
    return /* left as an exercise for the reader */;
} 

template <typename Iterator>
void print_special_numbers(const Iterator first, const Iterator last)
{
    for (auto iter = first; iter != last; ++iter)
    {
        const auto& x = *iter;
        const bool isEven = is_even(x);
        const bool isPrime = is_prime(x);

        if (isEven && isPrime)
            std::cout << "Special number! " << x << std::endl;
    }
}

Pourquoi sont les types de paramètres pour is_even et is_prime marqué const? Parce que d'un point de vue d'implémentation, changer le nombre que je teste serait une erreur! Pourquoi const auto& x? Parce que je n'ai pas l'intention de changer cette valeur, et je veux que le compilateur me crie dessus si je le fais. Idem avec isEven et isPrime: le résultat de ce test ne devrait pas changer, alors appliquez-le.

Bien sûr const les fonctions membres ne sont qu'un moyen de donner à this un type de la forme const T*. Il dit: "ce serait une erreur dans la mise en œuvre, si je devais changer certains de mes membres".

mutable dit "sauf moi". C'est de là que vient la "vieille" notion de "const logique". Envisager l' cas d'usage courant qu'il a donné: un membre mutex. Vous avez besoin de pour verrouiller ce mutex pour vous assurer que votre programme est correct, vous devez donc le modifier. Vous ne voulez pas que la fonction soit non-const, car ce serait une erreur de modifier un autre membre. Donc, vous le faites const et marquez le mutex comme mutable.

rien de tout cela n'a à voir avec la sécurité des fils.

Je pense que c'est un pas de trop pour dire que les nouvelles définitions remplacent les anciennes idées données ci-dessus; elles ne font que compléter d'un autre point de vue, celui de thread-sécurité.

Maintenant le point de vue d'Herbe donne que si vous avez const fonctions, ils doivent être thread-safe pour être utilisables en toute sécurité par la bibliothèque standard. En corollaire de ceci, les seuls membres que vous devriez vraiment marquer comme mutable sont ceux qui sont déjà thread-safe, car ils sont modifiables à partir d'une fonction const:

struct foo
{
    void act() const
    {
        mNotThreadSafe = "oh crap! const meant I would be thread-safe!";
    }

    mutable std::string mNotThreadSafe;
};

Ok, donc nous savons que les choses thread-safe peuvent être marquées comme mutable, vous demandez: devraient-elles l'être?

Je pense que nous devons considérer les deux vues simultanément. Du nouveau point de vue D'Herb, Oui. Ils sont thread safe donc n'ont pas besoin d'être liés par la const-ness de la fonction. Mais ce n'est pas parce qu'ils peuvent être excusés en toute sécurité des contraintes de const qu'ils doivent l'être. Je dois encore considérer: serait - ce une erreur dans la mise en œuvre si je modifiais ce membre? Si oui, il ne doit pas être mutable!

Il y a un problème de granularité ici: certaines fonctions peuvent besoin de modifier le membre mutable alors que d'autres ne le font pas. C'est comme vouloir seulement que certaines fonctions aient un accès semblable à un ami, mais nous ne pouvons qu'ami toute la classe. (C'est un problème de conception de langage.)

Dans ce cas, vous devriez vous tromper du côté de mutable.

Herb a parlé un peu trop lâchement quand il a donné un exemple const_cast un déclaré sûr. Considérez:

struct foo
{
    void act() const
    {
        const_cast<unsigned&>(counter)++;
    }

    unsigned counter;
};

Ceci est sûr dans la plupart des circonstances, sauf lorsque l'objet foo lui-même est const:

foo x;
x.act(); // okay

const foo y;
y.act(); // UB!

C'est couvertes ailleurs, mais const foo, implique l' counter membre est également const, et la modification d'une const objet est un comportement indéfini.

C'est pourquoi vous devriez vous tromper du côté de mutable: const_cast ne vous donne pas tout à fait les mêmes garanties. Si counter avait été marqué mutable, il n'aurait pas été un objet const.

Ok, donc si nous en avons besoin mutable en un seul endroit, nous en avons besoin partout, et nous devons juste faire attention dans les cas où nous ne le faisons pas. signifie que tous les membres thread-safe doivent être marqués mutable alors?

Eh bien non, car tous les membres thread-safe ne sont pas là pour la synchronisation Interne. L'exemple le plus trivial est une sorte de classe wrapper (pas toujours la meilleure pratique mais ils existent):

struct threadsafe_container_wrapper
{
    void missing_function_I_really_want()
    {
        container.do_this();
        container.do_that();
    }

    const_container_view other_missing_function_I_really_want() const
    {
        return container.const_view();
    }

    threadsafe_container container;
};

Ici, nous enveloppons threadsafe_container et fournissons une autre fonction membre que nous voulons (ce serait mieux en tant que fonction libre dans la pratique). Pas besoin de mutable ici, l'exactitude de l'ancien point de vue l'emporte complètement: dans une fonction Je modifie le conteneur et c'est correct parce que je n'ai pas dit que je ne le ferais pas (en omettant const), et dans l'autre, Je ne modifie pas le conteneur et je m'assure que je respecte cette promesse (en omettant mutable).

Je pense Que Herb argumente le plus de cas où nous utiliserions mutable nous utilisons également une sorte d'objet de synchronisation Interne (thread-safe), et je suis d'accord. Ergo son point de vue fonctionne la plupart du temps. Mais il existe des cas où j'arrive simplement à avoir un objet thread-safe et simplement le traiter comme un autre membre; dans ce cas, nous nous rabattons sur l'utilisation Ancienne et fondamentale de const.