¿La palabra clave C++ mutable es incorrecta para los hilos?

Question

Desde mi entendimiento de la palabra clave mutable, uno de sus usos principales es el almacenamiento en caché de datos y su computación cuando sea necesario. Como pueden cambiar (aunque sean const) no sería inseguro o inútil usarlos? La parte de almacenamiento en caché modifica los datos, por lo que debería haber un bloqueo y, según entiendo, al escribir en multihebra, los datos NUNCA deben cambiar y las copias deben realizarse y enviarse/encadenarse juntas.

¿No tiene sentido o es malo usar la palabra clave mutable de C++?

Answer 1

¿No tiene sentido o es malo usar la palabra clave mutable de C++?

No; la palabra clave mutable es A Good Thing. mutable se puede utilizar para separar el estado observable de un objeto de los contenidos internos del objeto.

Con el ejemplo de "datos en caché" que describe (un uso muy común de mutable), permite que la clase realice optimizaciones "debajo de las coberturas" que en realidad no modifican el estado observable.

Con respecto al acceso a un objeto de múltiples hilos, sí, debe tener cuidado. En general, si una clase está diseñada para acceder desde múltiples hilos y tiene variables mutable, debe sincronizar la modificación de esas variables internamente. Tenga en cuenta, sin embargo, que el problema es realmente más conceptual. Es fácil pensar que:

1. Todos mis procesos únicamente llaman métodos constantes en este objeto compartido
2. métodos constantes no modifican el objeto sobre el cual son llamados
3. Si un objeto no se modifica , no necesito para sincronizar el acceso a la misma
4. Por lo tanto, no necesito para sincronizar el acceso a este objeto

este argumento es erróneo debido a que (2) es falsa: métodos constantes de hecho puede modif y miembros de datos mutables. El problema es que es muy, muy fácil pensar que este argumento es correcto.

La solución a este problema no es fácil: efectivamente, solo tiene que ser extremadamente cuidadoso al escribir código multiproceso y estar absolutamente seguro de que comprende cómo se implementan los objetos compartidos entre subprocesos o qué concurrencia garantiza.

Answer 2

No, la palabra clave mutable es para que pueda tener campos dentro de un objeto que pueden cambiar incluso cuando el objeto es const, como para metadatos que no son parte de las propiedades de un objeto sino su gestión (como contadores, etc.). No tiene nada que ver con enhebrar.

Answer 3

En el extremo opuesto, la mayor parte de mi código multiproceso requiere el uso de la mutable palabra clave:

class object { 
    type m_data; 
    mutable mutex m_mutex; 
public: 
    void set(type const & value) { 
     scoped_lock lock(m_mutex); 
     m_data = value; 
    } 
    type get() const { 
     scoped_lock lock(m_mutex); 
     return m_data; 
    } 
}; 

El hecho de que el método get no modifica el estado de la object es declarado por medio de la palabra clave const.Pero sin el modificador mutable aplicado a la declaración del atributo mutex, el código no podría bloquear o liberar el mutex --ambas operaciones claramente modificar el mutex, incluso si no modifican el object.

Incluso puede hacer que el atributo data se modifique si puede evaluarse de forma diferida y el costo es alto, siempre que bloquee el objeto. Este es el uso del caché al que se refiere en la pregunta.

El modificador mutable no es un problema con el código multiproceso, solo cuando intenta hacer sin enclavamiento multihilo. Y al igual que con todos programación sin cerradura, debe ser muy cuidado con lo que hace, independientemente de const o const. Puede escribir código multiproceso perfectamente inseguro que llame a los métodos const en objetos sin atributos mutable. El ejemplo simple sería eliminar el mutex del código anterior y tener N hilos para realizar solo get() s, mientras que otro hilo realiza set() s. El hecho de que get() es const no es garantía de que no obtendrá resultados no válidos si otro hilo está modificando.