Dlaczego miałbym std :: przenieść std :: shared_ptr?

Przeglądałem kod źródłowy Clang i znalazłem ten fragment:

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

Dlaczego miałbym chcieć ?std::movestd::shared_ptr

Czy jest jakiś sens przenoszenia własności do udostępnionego zasobu?

Dlaczego nie miałbym po prostu tego zrobić?

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

Myślę, że jedyną rzeczą, na którą inne odpowiedzi nie zostały wystarczająco podkreślone, jest kwestia szybkości .

std::shared_ptrliczba odniesień jest atomowa . zwiększenie lub zmniejszenie liczby referencyjnej wymaga atomowego przyrostu lub zmniejszenia . Jest to sto razy wolniejsze niż nieatomowe zwiększanie / zmniejszanie, nie wspominając o tym, że jeśli zwiększamy i zmniejszamy ten sam licznik, otrzymujemy dokładną liczbę, marnując przy tym mnóstwo czasu i zasobów.

Przesuwając shared_ptrzamiast kopiować, „kradniemy” atomową liczbę odniesień i unieważniamy drugą shared_ptr. „Kradzież” liczby referencyjnej nie jest atomowa i jest sto razy szybsza niż kopiowanie shared_ptr(i powodowanie atomowego zwiększania lub zmniejszania wartości referencyjnej).

Zwróć uwagę, że ta technika jest używana wyłącznie do optymalizacji. kopiowanie go (jak sugerowałeś) jest równie dobre pod względem funkcjonalności.

Używając moveunikasz zwiększania, a następnie natychmiastowego zmniejszania liczby udziałów. To może zaoszczędzić ci drogich operacji atomowych na liczniku użycia.

Operacje przenoszenia (takie jak konstruktor przenoszenia) std::shared_ptrsą tanie , ponieważ w zasadzie są „wskaźnikami kradzieży” (ze źródła do celu; dokładniej mówiąc, cały blok kontroli stanu jest „skradziony” od źródła do celu, w tym informacje o liczbie referencyjnej) .

Zamiast tego operacje kopiowania przy std::shared_ptrwywołaniu niepodzielnego zwiększenia liczby referencji (tj. Nie tylko ++RefCountna składniku RefCountdanych całkowitych , ale np. Wywołanie InterlockedIncrementw systemie Windows) jest droższe niż zwykła kradzież wskaźników / stanu.

Tak więc, analizując szczegółowo dynamikę liczby ref w tym przypadku:

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

Jeśli przekażesz spwartość, a następnie weźmiesz kopię wewnątrz CompilerInstance::setInvocationmetody, masz:

1. Przy wejściu do metody shared_ptrparametr jest konstruowany jako kopia: ref count atomowy przyrost .
2. Wewnątrz ciała danej metody jest, to skopiuj ten shared_ptrparametr w elemencie danych: Ref liczyć atomową przyrost .
3. Po wyjściu z metody shared_ptrparametr zostaje zniszczony: ref count atomic decment .

Masz dwa atomowe przyrosty i jeden atomowy dekrement, co daje w sumie trzy atomowe operacje.

Zamiast tego, jeśli przekażesz shared_ptrparametr według wartości, a następnie std::movewewnątrz metody (tak jak zostało to prawidłowo zrobione w kodzie Clanga), masz:

1. Przy wejściu do metody shared_ptrparametr jest konstruowany jako kopia: ref count atomowy przyrost .
2. W treści metody std::moveumieszczasz shared_ptrparametr w składniku danych: liczba ref nie zmienia się! Po prostu kradniesz wskaźniki / stan: nie są zaangażowane żadne kosztowne atomowe operacje liczenia referencji.
3. Podczas wychodzenia z metody shared_ptrparametr zostaje zniszczony; ale ponieważ przeszedłeś w kroku 2, nie ma nic do zniszczenia, ponieważ shared_ptrparametr już na nic nie wskazuje. Ponownie, w tym przypadku nie dochodzi do dekrementacji atomowej.

Konkluzja: w tym przypadku otrzymujesz tylko jeden atomowy przyrost liczby ref, tj. Tylko jedną atomową operację.
Jak widać, jest to znacznie lepsze niż dwa atomowe przyrosty plus jeden atomowy dekrement (w sumie trzy atomowe operacje) dla wielkości kopii.

Kopiowanie shared_ptrobejmuje kopiowanie wewnętrznego wskaźnika obiektu stanu i zmianę liczby odwołań. Przeniesienie obejmuje tylko zamianę wskaźników do wewnętrznego licznika odwołań i posiadanego obiektu, więc jest szybsze.

Istnieją dwa powody używania std :: move w tej sytuacji. Większość odpowiedzi dotyczyła kwestii szybkości, ale zignorowała ważną kwestię wyraźniejszego pokazania intencji kodu.

Dla std :: shared_ptr, std :: move jednoznacznie oznacza przeniesienie własności wskazanego, podczas gdy prosta operacja kopiowania dodaje dodatkowego właściciela. Oczywiście, jeśli pierwotny właściciel zrzeka się później swojej własności (na przykład pozwalając na zniszczenie ich std :: shared_ptr), wówczas przeniesienie własności zostało zrealizowane.

Kiedy przenosisz własność za pomocą std :: move, oczywiste jest, co się dzieje. Jeśli używasz zwykłej kopii, nie jest oczywiste, że zamierzoną operacją jest przeniesienie, dopóki nie zweryfikujesz, że pierwotny właściciel natychmiast zrzeka się prawa własności. Jako bonus możliwa jest wydajniejsza implementacja, ponieważ atomowe przeniesienie własności może uniknąć stanu tymczasowego, w którym liczba właścicieli wzrosła o jednego (i związane z tym zmiany w liczbie referencyjnej).

Przynajmniej z libstdc ++ powinieneś uzyskać taką samą wydajność z przenoszeniem i przypisywaniem, ponieważ operator=wywołuje std::moveprzychodzący wskaźnik. Zobacz: https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/shared_ptr.h#L384