Arc::make_mut cerca di fornire accesso mutabile ai dati interni verificando prima che l'Arc detenga l'unica referenza forte all'allocazione. Esegue questo controllo utilizzando un caricamento atomico con ordinamento Acquire sul conteggio delle referenze forti. Se il conteggio è esattamente uno, l'operazione procede a restituire un riferimento mutabile; altrimenti, clona i dati interni e aggiorna l'Arc per puntare alla nuova allocazione.
use std::sync::Arc; let mut data = Arc::new(5); *Arc::make_mut(&mut data) += 1; // Clona solo se condiviso
La coppia Acquire/Release è essenziale perché quando un altro thread rilascia il proprio Arc, esegue un decremento Release sul conteggio. Il caricamento Acquire in make_mut garantisce che tutte le scritture di memoria effettuate dal thread che rilascia prima del decremento siano visibili al thread corrente, prevenendo le data race sui dati interni.
Considera un servizio di aggregazione di metriche ad alta capacità in cui gli aggiornamenti di configurazione sono propagati tramite Arc<Config>. Migliaia di thread detengono referenze per leggere le impostazioni correnti, ma il thread amministratore deve periodicamente regolare le soglie senza riavviare il servizio.
L'approccio ingenuo è avvolgere il Config in un RwLock e bloccarlo per ogni lettura, o clonare l'intera struttura per ogni aggiornamento minore a prescindere dalla condivisione. La prima soluzione soffre di bouncing della cache e overhead di blocco, mentre la seconda spreca memoria e cicli CPU su allocazioni ridondanti quando la configurazione è effettivamente unica.
Un'alternativa è utilizzare AtomicPtr con puntatori di pericolo per aggiornamenti senza blocchi, ma questo richiede una gestione complessa della memoria manuale ed è soggetto a errori. Un'altra opzione è usare un RwLock<Arc<Config>>, consentendo scambi atomici del puntatore stesso, ma questo aggiunge un'ulteriore indirezione e un blocco per lo scambio del puntatore.
Il team ha scelto Arc::make_mut perché ottimizza il caso comune: se nessun altro thread detiene una referenza (il conteggio forte è 1), il thread amministratore modifica i dati in loco senza allocazione. Se la configurazione è condivisa, clona in modo trasparente. Questo richiede le rigorose semantiche Acquire/Release per garantire che quando l'ultimo altro lettore rilascia il proprio Arc (utilizzando Release), il controllo successivo del thread amministratore (utilizzando Acquire) veda tutte le scritture precedenti alla configurazione, prevenendo letture lacerate. Il risultato è stato una riduzione del 40% della latenza per gli aggiornamenti di configurazione in condizioni di bassa contesa.
Perché non può essere utilizzato l'ordinamento Relaxed per il controllo del conteggio delle referenze in Arc::make_mut?
Le operazioni Relaxed non forniscono garanzie di happens-before. Se make_mut utilizzasse Relaxed per verificare se il conteggio forte è 1, potrebbe osservare il decremento del conteggio da un altro thread prima di osservare le scritture di quel thread ai dati interni. Questo consentirebbe al thread corrente di modificare i dati mentre un altro thread li sta ancora leggendo logicamente, causando una data race. Acquire garantisce che quando vediamo il conteggio raggiungere 1 (synchronized tramite il Release nel drop dell'altro thread), vediamo anche tutte le scritture precedenti ai dati.
Cosa distingue il comportamento di Arc::make_mut dal clonare manualmente l'Arc con .clone() seguito da una modifica?
Clonare manualmente crea un nuovo Arc che punta alla stessa allocazione, incrementando il conteggio forte ad almeno 2. Non puoi ottenere accesso mutabile ai dati interni tramite questo nuovo Arc perché Arc fornisce solo una condivisione immutabile. Arc::make_mut è speciale perché verifica se il conteggio è 1; in tal caso, fornisce &mut T all'allocazione esistente. Se no, clona i dati in una nuova allocazione con un conteggio di 1, garantendo che i dati condivisi originali rimangano immutabili mentre ti fornisce la proprietà unica della nuova copia.
Come influenzano i puntatori deboli (Arc::downgrade) la garanzia di unicità di Arc::make_mut?
I puntatori deboli non partecipano al conteggio delle referenze forti. Arc::make_mut verifica solo il conteggio forte, ignorando i riferimenti deboli. Tuttavia, i puntatori deboli possono essere aggiornati in referenze forti se l'allocazione esiste ancora. Se make_mut procede con la mutazione in loco (il conteggio forte è 1), e un altro thread successivamente aggiorna un puntatore debole, quell'aggiornamento creerà un nuovo Arc che punta agli stessi dati mutati. Questo è sicuro perché l'aggiornamento avviene dopo la mutazione, e il modello di memoria di Rust garantisce che il puntatore aggiornato veda il valore completamente modificato. Il conteggio debole non impedisce la mutazione, ma mantiene viva l'allocazione anche se tutte le referenze forti sono temporaneamente rilasciate.