Qual è l'overhead di shared_ptr che è thread-safe?

Question

std::shared_ptr è sicuro per essere thread-safe. Non so quale meccanismo utilizzi le tipiche implementazioni per garantire questo, ma sicuramente deve avere un sovraccarico. E quell'overhead sarebbe presente anche nel caso in cui la tua applicazione fosse a thread singolo.

È il caso precedente? E se è così, vuol dire che viola il principio di "non paghi per ciò che non usi", se non stai utilizzando le garanzie di sicurezza del thread?

Answer 1

Almeno nel codice boost su i386, boost::shared_ptr è stato implementato utilizzando un'operazione CAS atomica. Ciò significa che mentre ha un sovraccarico, è piuttosto basso. Mi aspetto che qualsiasi implementazione di std::shared_ptr sia simile.

In loop stretti nel codice numerico ad alte prestazioni ho trovato alcuni accelerazioni passando a puntatori grezzi e facendo molta attenzione. Ma per codice normale - non me ne preoccuperei.

Answer 2

Se controlliamo fuori cppreference pagina dedicata std::shared_ptr affermano quanto segue nella Note di attuazione sezione:

per soddisfare i requisiti di sicurezza filo, i contatori di riferimento sono tipicamente incrementato e decrementato usando std::atomic::fetch_add con std::memory_order_relaxed.

E 'interessante notare un'implementazione reale, ad esempio il documento libstdc++ implementazione here dice:

Per la versione di shared_ptr nel libstdC++ il compilatore e la biblioteca sono fissi, il che rende le cose molto più semplici : non abbiamo un CAS atomico o , per i dettagli vedere Lock Policy qui sotto.

Il Selezionando la politica di blocco sezione dice (sottolineatura mia):

V'è una sola classe _Sp_counted_base, che è un modello con parametri sul enum __gnu_cxx :: _ Lock_policy. L'intera famiglia di classi è parametrizzata sulla politica di blocco, fino a __shared_ptr, __weak_ptr e __enable_shared_from_this. L'attuale classe std :: shared_ptr eredita dalla __shared_ptr con la politica di blocco parametro selezionata automaticamente in base al modello di thread e piattaforma che libstdC++ configurato per, in modo che i migliori disponibili modello di specializzazione sarà utilizzato. Questo design è necessario perché non sarebbe conforme per shared_ptr per avere un parametro aggiuntivo modello , anche se aveva un valore predefinito. Le politiche disponibili sono:

[...]

3._S_Single

Questa politica utilizza un add_ref_lock non rientrante() senza bloccaggio. Viene utilizzato quando libstdC++ viene creato senza --enable-threads.

e ulteriormente dice (sottolineatura mia):

Per tutte e tre le politiche, con incrementi di conteggio di riferimento e decrementi sono fatto tramite le funzioni in ext/atomicity.h, che rilevano se il programma è multi-threaded. Se nel programma esiste un solo thread di esecuzione, vengono utilizzate operazioni non atomiche meno costose.

Quindi almeno in questa implementazione non si paga per quello che non si usa.