Const signifie-t-il thread-safe en C ++ 11?

J'entends que cela constsignifie thread-safe dans C ++ 11 . Est-ce vrai?

Est -ce que cela veut dire constest maintenant l'équivalent de Java desynchronized ?

Sont-ils à court de mots clés ?

J'entends que cela constsignifie thread-safe en C ++ 11 . Est-ce vrai?

C'est un peu vrai ...

Voici ce que dit le langage standard sur la sécurité des threads:

[1.10 / 4] Deux évaluations d'expression sont en conflit si l'une d'elles modifie un emplacement mémoire (1.7) et l'autre accède ou modifie le même emplacement mémoire.

[1.10 / 21] L'exécution d'un programme contient une course aux données si elle contient deux actions conflictuelles dans des threads différents, dont au moins une n'est pas atomique, et aucune ne se produit avant l'autre. Une telle course aux données entraîne un comportement indéfini.

ce qui n'est rien d'autre que la condition suffisante pour qu'une course aux données se produise:

1. Il y a deux ou plusieurs actions exécutées en même temps sur une chose donnée; et
2. Au moins l'un d'entre eux est une écriture.

La bibliothèque standard s'appuie sur cela, en allant un peu plus loin:

[17.6.5.9/1] Cette section spécifie les exigences que les implémentations doivent satisfaire pour empêcher les courses de données (1.10). Chaque fonction de bibliothèque standard doit satisfaire à chaque exigence sauf indication contraire. Les implémentations peuvent empêcher les courses de données dans des cas autres que ceux spécifiés ci-dessous.

[17.6.5.9/3] Une fonction de bibliothèque standard C ++ ne doit pas modifier directement ou indirectement les objets (1.10) accessibles par des threads autres que le thread courant à moins que les objets ne soient accédés directement ou indirectement via lesargumentsnon const de la fonction, y compristhis.

qui en termes simples dit qu'il s'attend à ce que les opérations sur les constobjets soient thread-safe . Cela signifie que la bibliothèque standard n'introduira pas de course aux données tant que les opérations sur les constobjets de vos propres types non plus

1. Se compose entièrement de lectures - c'est-à-dire qu'il n'y a pas d'écritures -; ou
2. Synchronise les écritures en interne.

Si cette attente ne tient pas pour l'un de vos types, son utilisation directe ou indirecte avec n'importe quel composant de la bibliothèque standard peut entraîner une course aux données . En conclusion, constcela signifie thread-safe du point de vue de la bibliothèque standard . Il est important de noter qu'il ne s'agit que d'un contrat et qu'il ne sera pas appliqué par le compilateur, si vous le rompez, vous obtenez un comportement indéfini et vous êtes seul. Que ce constsoit présent ou non n'affectera pas la génération de code - du moins pas en ce qui concerne les courses de données -.

Est -ce que cela veut dire constest maintenant l'équivalent de Java desynchronized ?

Non . Pas du tout...

Considérez la classe trop simplifiée suivante représentant un rectangle:

class rect {
    int width = 0, height = 0;

public:
    /*...*/
    void set_size( int new_width, int new_height ) {
        width = new_width;
        height = new_height;
    }
    int area() const {
        return width * height;
    }
};

La fonction membre area est thread-safe ; non pas parce constque c'est, mais parce qu'il consiste entièrement en opérations de lecture. Aucune écriture n'est impliquée et au moins une écriture impliquée est nécessaire pour qu'une course aux données se produise. Cela signifie que vous pouvez appeler à areapartir d'autant de threads que vous le souhaitez et que vous obtiendrez des résultats corrects à tout moment.

Notez que cela ne signifie pas que rectc'est thread-safe . En fait, il est facile de voir comment si un appel à areadevait se produire en même temps qu'un appel à set_sizesur une donnée rect, alors areapourrait finir par calculer son résultat basé sur une ancienne largeur et une nouvelle hauteur (ou même sur des valeurs brouillées) .

Mais c'est bien, rectn'est-ce pas constsi ce n'est même pas censé être thread-safe après tout. Un objet déclaré const rect, en revanche, serait thread-safe car aucune écriture n'est possible (et si vous envisagez const_cast-ing quelque chose initialement déclaré, constvous obtenez un comportement indéfini et c'est tout).

Alors qu'est-ce que cela signifie alors?

Supposons - pour des raisons d'argumentation - que les opérations de multiplication sont extrêmement coûteuses et il vaut mieux les éviter lorsque cela est possible. Nous pourrions calculer la zone uniquement si elle est demandée, puis la mettre en cache au cas où elle serait à nouveau demandée à l'avenir:

class rect {
    int width = 0, height = 0;

    mutable int cached_area = 0;
    mutable bool cached_area_valid = true;

public:
    /*...*/
    void set_size( int new_width, int new_height ) {
        cached_area_valid = ( width == new_width && height == new_height );
        width = new_width;
        height = new_height;
    }
    int area() const {
        if( !cached_area_valid ) {
            cached_area = width;
            cached_area *= height;
            cached_area_valid = true;
        }
        return cached_area;
    }
};

[Si cet exemple semble trop artificiel, vous pouvez le remplacer mentalement intpar un très grand entier alloué dynamiquement qui est par nature non thread-safe et pour lequel les multiplications sont extrêmement coûteuses.]

La fonction membre area n'est plus thread-safe , elle effectue des écritures maintenant et n'est pas synchronisée en interne. C'est un problème? L'appel à areapeut se produire dans le cadre d'un constructeur de copie d'un autre objet, un tel constructeur aurait pu être appelé par une opération sur un conteneur standard , et à ce stade, la bibliothèque standard s'attend à ce que cette opération se comporte comme une lecture en ce qui concerne les courses de données . Mais nous faisons des écritures!

Dès que nous mettons un rectdans un conteneur standard - directement ou indirectement - nous concluons un contrat avec la bibliothèque standard . Pour continuer à faire des écritures dans une constfonction tout en respectant ce contrat, nous devons synchroniser ces écritures en interne:

class rect {
    int width = 0, height = 0;

    mutable std::mutex cache_mutex;
    mutable int cached_area = 0;
    mutable bool cached_area_valid = true;

public:
    /*...*/
    void set_size( int new_width, int new_height ) {
        if( new_width != width || new_height != height )
        {
            std::lock_guard< std::mutex > guard( cache_mutex );
        
            cached_area_valid = false;
        }
        width = new_width;
        height = new_height;
    }
    int area() const {
        std::lock_guard< std::mutex > guard( cache_mutex );
        
        if( !cached_area_valid ) {
            cached_area = width;
            cached_area *= height;
            cached_area_valid = true;
        }
        return cached_area;
    }
};

Notez que nous avons rendu la areafonction thread-safe , mais que ce rectn'est toujours pas thread-safe . Un appel à se areaproduire en même temps qu'un appel à set_sizepeut encore finir par calculer la mauvaise valeur, car les affectations à widthet heightne sont pas protégées par le mutex.

Si nous voulions vraiment un thread-safe rect , nous utiliserions une primitive de synchronisation pour protéger le non-thread-safe rect .

Sont-ils à court de mots clés ?

Oui, ils sont. Ils sont à court de mots clés depuis le premier jour.

Source : Vous ne savez pas constetmutable - Herb Sutter