Cómo usar Arc para reducir clones en una caché concurrente de Rust
El autor reemplaza los valores clonados de una caché protegida por RWLock con Arc, logrando referencias más ligeras y manteniendo la seguridad del tipo.
En un driver de compilación escrito en Rust el autor descubrió que cada llamada a Proxy::get clonaba dos veces un valor JSON, lo que anulaba los beneficios de la caché cuando los objetos eran grandes. Para evitar esas copias costosas sustituyó los valores almacenados en el HashMap por Arc<JSON>.
Con Arc la operación de clonar solo incrementa un contador atómico, por lo que el coste es prácticamente constante. La implementación queda prácticamente idéntica, sólo cambian tres líneas: el tipo del mapa pasa a HashMap<String, Arc<JSON>>, el método get devuelve Arc<JSON> y la inserción clona el Arc en vez del valor completo.
struct Proxy {
client: HTTPClient,
cache: RWLock<HashMap<String, Arc<JSON>>>,
}
impl Proxy {
fn get(&self, url: &str) -> Arc<JSON> {
let cache = self.cache.read().unwrap();
if let Some(v) = cache.get(url) { return v.clone(); }
let value = Arc::new(self.client.get(url));
let mut cache = self.cache.write().unwrap();
cache.insert(url.to_string(), value.clone());
value
}
}
Esta solución elimina los clones profundos, pero introduce un nuevo problema: la falta de downcasting directo desde Arc<JSON> a Arc<String>. En Rust el método deref devuelve una referencia cuyo tiempo de vida termina al salir de la función, impidiendo crear un Arc del interior sin copiarlo nuevamente. El artículo muestra que, aunque se pueda obtener &String mediante pattern‑matching, no es posible producir un Arc<String> sin incurrir en un nuevo clone.
La limitación se debe a que Arc mantiene la información de recuento sólo para el puntero original; cualquier sub‑puntero carece de esa metadata. Por tanto, la única forma segura de “downcast” es extraer una referencia y, si se necesita propiedad, volver a clonar el Arc completo. El autor sugiere que, en muchos casos, una referencia temporal (&JSON) es suficiente, o bien considerar diseños donde el tipo concreto se conozca de antemano y no se requiera downcasting.
Implicaciones para la arquitectura
Adoptar Arc en cachés compartidas es una práctica recomendada cuando los valores son costosos de copiar y el acceso es mayormente de solo lectura. Sin embargo, si la aplicación necesita frecuentemente extraer variantes específicas del enum y trabajar con ellas como valores propios, se debe planificar un mecanismo de downcasting que no implique clones adicionales, quizá mediante tipos de contenedor personalizados o usando crates como slotmap o dumpster que ofrecen identificadores sin copiar datos.
En cualquier caso, la solución presentada muestra que el coste de los clones puede ser mitigado sin sacrificar la seguridad de los locks, pero que el modelo de propiedad de Rust sigue imponiendo restricciones al intentar combinar punteros de conteo atómico con downcasting de tipos complejos.
