Perché dovrei std :: move an std :: shared_ptr?

Ho cercato il codice sorgente di Clang e ho trovato questo frammento:

void CompilerInstance::setInvocation(
    std::shared_ptr<CompilerInvocation> Value) {
  Invocation = std::move(Value);
}

Perché dovrei voler std::moveun std::shared_ptr?

C'è qualche punto che trasferisce la proprietà su una risorsa condivisa?

Perché non dovrei fare questo invece?

void CompilerInstance::setInvocation(
    std::shared_ptr<CompilerInvocation> Value) {
  Invocation = Value;
}

Penso che l'unica cosa che l'altra risposta non abbia sottolineato abbastanza sia il punto di velocità .

std::shared_ptril conteggio dei riferimenti è atomico . l'aumento o la riduzione del conteggio di riferimento richiede un incremento o un decremento atomico . Questo è cento volte più lento di quanto non-atomica incremento / decremento, per non parlare che se noi di incremento e decremento lo stesso contatore finiamo con il numero esatto, sprecando un sacco di tempo e risorse nel processo.

Spostando shared_ptrinvece di copiarlo, "rubiamo" il conteggio dei riferimenti atomici e annulliamo l'altro shared_ptr. "rubare" il conteggio dei riferimenti non è atomico , ed è cento volte più veloce rispetto alla copia del shared_ptr(e causando incremento o decremento del riferimento atomico ).

Si noti che questa tecnica viene utilizzata esclusivamente per l'ottimizzazione. copiarlo (come hai suggerito) è altrettanto funzionale dal punto di vista funzionale.

Usando movesi evita di aumentare, e quindi immediatamente diminuire, il numero di condivisioni. Ciò potrebbe farti risparmiare alcune costose operazioni atomiche sul conteggio degli usi.

Le operazioni di spostamento (come il costruttore di spostamenti) std::shared_ptrsono economiche , in quanto sostanzialmente "rubano puntatori" (dalla sorgente alla destinazione; per essere più precisi, l'intero blocco di controllo dello stato viene "rubato" dalla sorgente alla destinazione, comprese le informazioni sul conteggio dei riferimenti) .

Invece le operazioni di copiastd::shared_ptr sull'invocazione aumentano il conteggio dei riferimenti atomici (cioè non solo ++RefCountsu un RefCountmembro di dati interi , ma ad esempio chiamando InterlockedIncrementsu Windows), che è più costoso del semplice rubare puntatori / stato.

Quindi, analizzando in dettaglio la dinamica del conteggio di riferimento di questo caso:

// shared_ptr<CompilerInvocation> sp;
compilerInstance.setInvocation(sp);

Se passi spper valore e poi ne esegui una copia all'interno del CompilerInstance::setInvocationmetodo, hai:

1. Quando si immette il metodo, il shared_ptrparametro viene creato come copia: incremento del conteggio atomico .
2. All'interno del corpo del metodo, si copia il shared_ptrparametro nel membro dati: ref count incremento atomico .
3. All'uscita dal metodo, il shared_ptrparametro viene distrutto: ref count decremento atomico .

Hai due incrementi atomici e un decremento atomico, per un totale di tre operazioni atomiche .

Invece, se passi il shared_ptrparametro per valore e poi std::moveall'interno del metodo (come correttamente fatto nel codice di Clang), hai:

1. Quando si immette il metodo, il shared_ptrparametro viene creato come copia: incremento del conteggio atomico .
2. All'interno del corpo del metodo, è std::moveil shared_ptrparametro nell'elemento dati: il conteggio dei riferimenti non cambia! Stai solo rubando puntatori / stato: non sono coinvolte costose operazioni di conteggio dei riferimenti atomici.
3. All'uscita dal metodo, il shared_ptrparametro viene distrutto; ma poiché ti sei spostato nel passaggio 2, non c'è nulla da distruggere, poiché il shared_ptrparametro non punta più a nulla. Ancora una volta, in questo caso non si verifica alcun decremento atomico.

In conclusione: in questo caso si ottiene solo un incremento atomico del conteggio dei riferimenti, ovvero solo un'operazione atomica .
Come puoi vedere, è molto meglio di due incrementi atomici più un decremento atomico (per un totale di tre operazioni atomiche) per il caso della copia.

La copia di a shared_ptrcomporta la copia del puntatore dell'oggetto stato interno e la modifica del conteggio dei riferimenti. Lo spostamento implica solo lo scambio di puntatori al contatore di riferimento interno e all'oggetto posseduto, quindi è più veloce.

Ci sono due ragioni per usare std :: move in questa situazione. La maggior parte delle risposte ha affrontato il problema della velocità, ma ha ignorato l'importante problema di mostrare più chiaramente l'intento del codice.

Per uno std :: shared_ptr, std :: move indica inequivocabilmente un trasferimento di proprietà della punta, mentre una semplice operazione di copia aggiunge un ulteriore proprietario. Naturalmente, se il proprietario originale successivamente cede la propria proprietà (ad esempio consentendo la distruzione del proprio std :: shared_ptr), è stato eseguito un trasferimento di proprietà.

Quando trasferisci la proprietà con std :: move, è ovvio cosa sta succedendo. Se si utilizza una copia normale, non è ovvio che l'operazione prevista è un trasferimento fino a quando non si verifica che il proprietario originale ceda immediatamente la proprietà. Come bonus, è possibile un'implementazione più efficiente, dal momento che un trasferimento atomico di proprietà può evitare lo stato temporaneo in cui il numero di proprietari è aumentato di uno (e l'operatore cambia nei conteggi di riferimento).

Almeno con libstdc ++ dovresti ottenere le stesse prestazioni con spostamento e assegnazione perché operator=chiama std::moveil puntatore in arrivo. Vedi: https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/shared_ptr.h#L384