2017-10-19 5 views
0

Est-il possible dans atomic_compare_exchange_strong de shared_ptr de comparer avec le pointeur brut?shared_ptr's std :: atomic_compare_exchange_strong comparaison avec le pointeur brut

Comme si:

struct Chunk{ 
     // atomics 
     std::shared_ptr<Chunk> prev; 
     std::shared_ptr<Chunk> next; 
    }; 

    // chunk is guaranteed to stay alive while this operation 
    void remove_chunk(Chunk* chunk){ 
     std::shared_ptr<Chunk> prev = std::atomic_load(&chunk->prev); 
     std::shared_ptr<Chunk> next = std::atomic_load(&chunk->next); 

     // Can I do this? 
     std::shared_ptr<Chunk> self{chunk}; 
     std::atomic_compare_exchange_strong(&prev, &self, next); 

     ... 
    }; 

Je pensais à cela, parce que http://en.cppreference.com/w/cpp/memory/shared_ptr/operator_cmp dit que par rapport uniquement des pointeurs premières. Mais est-ce exigé par standart, ou juste effet secondaire d'optimisation?

La question est seulement environ atomic_compare_exchange_strong exactitude.

Répondre

1

Presque certainement, c'est faux. Dans remove_chunk(Chunk* chunk), chunk est probablement simplement l'identification du morceau à supprimer. Dans std::shared_ptr<Chunk> self{chunk};, vous impliquez que vous étiez le propriétaire de chunk, et self devient le nouveau propriétaire.

+0

«chunk» est garanti pour rester en vie pendant cette opération. – tower120

+0

@ tower120: Eh bien, non, car 'self' prend la propriété de force, le transfère à' prev', qui sort alors de sa portée et supprime le morceau. Votre déclaration indique que vous auriez vraiment dû écrire 'remove_chunk (Chunk & chunk)' et ensuite le compilateur aurait attrapé le bogue. – MSalters

+0

putain tu as raison. Là où le verrou global avant, maintenant je suis passé à verrou par morceau ... – tower120