Discussion :

[Kalith]

Bonjour,

Je découvre actuellement les joies de la programmation concurrente, et suis tombé sur un bel article faisant usage de std::atomic<T*> pour créer une file thread safe et sans lock.

Dans cet article justement, l'auteur (Herb Sutter) utilise le type std::atomic<T*> comme s'il s'agissait d'un pointeur normal, c'est à dire en substance :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
struct node {
    node* next;
};
std::atomic<node*> some_node = ...;
some_node = some_node->next;

Or, j'ai beau regarder dans mon implémentation (GCC 4.7) et sur les sites décrivant la nouvelle norme C++11 (click), il n'est fait mention nulle part que std::atomic<T*> dispose d'un T* operator -> () (i.e. le code ci-dessus génère une erreur à la ligne 5).

J'ai donc deux questions :

• Sutter fume-t-il de l'herbe ?
• Pourquoi cet opérateur n'est-il pas ajouté à la spécialisation de std::atomic<T> pour T = U* ?

Si vous connaissez la réponse à la seconde (la première m'intéresse moins), je suis intéressé.

[gbdivers]

Tu n'es pas le seul, d'autre personnes font la remarque dans les commentaires que le code n'est pas compilable.
L'article date de 2008, donc probablement pas compilé avec gcc 4.7 (et donc pré-norme). Peut être qu'il utilisait une implémentation personnelle de atomic avec des features qui n'ont pas été conservé par la suite ?

[Kalith]

Ils parlent d'un autre soucis dans les commentaires, qui a été corrigé depuis : le fait d'écrire <node> perturbait le code de mise en forme du site. Mais je suis d'accord avec toi sur le fait qu'il doit s'agir d'une implémentation maison.

Ma seconde question demeure toutefois : pour quelle raison cet opérateur bien pratique est-t-il absent ? On peut contourner le problème en écrivant (*some_node).next à la place, mais ce n'est pas très élégant.

[gbdivers]

/mode pêche aux devinettes

Petite réflexion. Quand tu écris

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

std::atomic<node*> some_node = ...;

Le pointeur est atomic, mais par contre, l'objet pointé ne l'ai pas (je pense). Du coup *some_node n'est pas atomic et l'écriture some_node->next est peut être confuse (puisque l'on peut penser que le type est atomic alors que ce n'est pas le cas)
Du coup, un tel code n'est pas safe :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

some_node->next = another_node;

Par contre, le code de Herb :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

some_node = some_node->next;

est safe, puisque l'on transforme le type non atomic some_node->next en atomic

[Kalith]

Oui, je n'ai a vrai dire pas fait attention à la sémantique ici, juste à la forme. Il se trouve que *some_node est un raccourcis d'écriture pour some_node.load(), qui est une opération atomique (mais effectivement, les opérations sur la valeur pointée n'ont aucune garantie d'atomicité).

l'écriture some_node->next est peut être confuse (puisque l'on peut penser que le type est atomic alors que ce n'est pas le cas)

Moui, c'est aussi le cas de (*some_node).next, même si le fait que ce soit une syntaxe inhabituelle peut mettre la puce à l'oreille.

Dans l'ancienne norme, l'opérateur flèche sur les éléments de conteneur n'étaient pas spécifié, même si de nombreux compilateurs le fournissaient.

Tu veux dire en C++03 ? En tout cas c'est bel et bien spécifié dans la norme actuelle (cf. 13.5.6), or c'est dans celle-ci qu'a été introduit std::atomic.

[oodini]

Tu veux dire en C++03 ? En tout cas c'est bel et bien spécifié dans la norme actuelle (cf. 13.5.6), or c'est dans celle-ci qu'a été introduit std::atomic.

Je n'ai pas été assez clair. Je parlais en fait des itérateurs. L'opérateur flèche n'était pas spécifié pour les itérateurs, il me semble. En tout cas, pour C++11, il n'est défini que pour les itérateurs d'entrée.

[oodini]

Dans l'ancienne norme, l'opérateur flèche sur les éléments de conteneur n'étaient pas spécifié, même si de nombreux compilateurs le fournissaient.

Peut-être est-ce par souci de cohérence ?