Copia de mutex en Go: mantener la identidad del bloqueo junto con el estado que protege

Qué es

La documentación del paquete sync de Go indica que un Mutex no debe copiarse después de su primer uso. Su relación de sincronización conecta las operaciones de desbloqueo y bloqueo sobre ese mismo mutex. Por ello, una estructura que contiene un mutex necesita una convención de propiedad y de paso que conserve la identidad del objeto de sincronización durante todo su ciclo de vida activo. Go sync Mutex

Por qué importa

Un agente puede añadir un campo mutex y llamadas de bloqueo sin revisar cómo se pasa el objeto que los contiene. Un receptor por valor o una asignación pueden socavar la disciplina de un único bloqueo que se pretendía aplicar. La revisión propuesta sigue al objeto a través de constructores, métodos, colecciones y funciones auxiliares antes de evaluar cada sección crítica por separado.

Cómo aplicarlo

• Identifica el estado que protege cada mutex y el objeto exacto que lo contiene. Escribe el invariante de que todo acceso debe compartir la misma identidad de bloqueo.
• Inspecciona los receptores de métodos, los parámetros de funciones, los valores de retorno y las asignaciones que involucren al tipo contenedor. Revisa las operaciones sobre contenedores y las variables de iteración, que pueden introducir copias por valor.
• Elige una convención de propiedad explícita, normalmente pasar un puntero al propietario estable, y alinea la API con ella. No expongas una operación de copia cómoda que contradiga la regla del ciclo de vida.
• Si los llamadores necesitan una instantánea, construye un resultado aparte que contenga solo datos, mientras mantienes el bloqueo adecuado. Define qué valores se copian y si los datos mutables anidados siguen compartidos.
• Propón un caso de prueba de regresión que use las rutas reales de funciones auxiliares y contenedores que antes copiaban al propietario. Verifica el comportamiento del estado compartido y ejecuta las comprobaciones estáticas y de concurrencia pertinentes disponibles en el proyecto.

Trampas

Un receptor por puntero, por sí solo, no impide una copia explícita en otro lugar. Tampoco el hecho de preservar la identidad del mutex establece un orden de bloqueo correcto ni protege los accesos que omiten el bloqueo. Revisa por separado las copias anteriores al primer uso y las copias prohibidas de un estado activo; evita depender de un contrato de clonación no documentado. Esta es una auditoría de propiedad propuesta, y no se afirma ningún resultado de análisis estático ni de pruebas de condiciones de carrera.