Discussion :

[karastojko]

Salut,

Je lis un livre C++ Concurrency in Action, et je suis pas sûr que je comprends que pop() de lock-free stack doit être si complexe. Alors, l'auteur propose de réaliser un lock-free stack comme

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
 
template<typename T>
class lock_free_stack
{
private:
 
    struct node
    {
        std::shared_ptr<T> data;
        node* next;
        node(T const& data_) : data(std::make_shared<T>(data_))
        {}
    };
 
    std::atomic<node*> head;
 
public:
 
    void push(T const& data)
    {
        node* const new_node = new node(data);
        new_node->next = head.load();
        while(!head.compare_exchange_weak(new_node->next, new_node))
            ;
    }
 
    std::shared_ptr<T> pop()
    {
        node* old_head = head.load();
        while(old_head && !head.compare_exchange_weak(old_head, old_head->next))
            ;
        return old_head ? old_head->data : std::shared_ptr<T>();
    }
};

L'opération push() marche bien, mais pop() souffre d'un memory leak - old_head est jamais détruit. Donc, la solution proposée (dans le chapitre prochain) est comme un petit GC - comptes les éléments effacés, etc.

Ce que je ne comprends pas est - pourqoi on peut pas utiliser

Code :

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

atomic<shared_ptr<node>> head

au lieu de

Code :

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

atomic<node*> head

dans lock_free_stack et comme ça obtenir l'accès atomique sauf la fuite de mémoire? Est-ce que atomic<shared_ptr<node>> assure l'accès atomique?

Merci d'avance

[karastojko]

Selon http://en.cppreference.com/w/cpp/mem...red_ptr/atomic il est possible d'effectuer les opérations atomique sur shared_ptr. Donc, je dirais qu'il y a de raison d'utiliser

Code :

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

shared_ptr<T> head

au lieu de

Code :

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

atomic<node*> head

avec les lock-free opérations. Comme ça, l'implementation de lock-free stack serait facile. Quand même, il me parait étrange que l'auteur de livre (et aussi de thread bibliothèque en C++) n'étais pas informé au sujet de shared_ptr.