sync/atomic: Operaciones de hardware para alta concurrencia

Cuando optimizamos código para sistemas de alta concurrencia, el primer instinto suele ser envolver todo en un sync.Mutex. Sin embargo, los mutex son mecanismos de software: el scheduler de Go debe intervenir, poner las goroutines en espera y gestionar el despertar de las mismas cuando el lock se libera. Esto implica un coste de context switching y latencia.

sync/atomic ofrece una vía alternativa utilizando instrucciones directamente implementadas por la CPU, como LOCK XADD (para incrementos) o Compare-and-Swap (CAS). Al usar operaciones atómicas, le estamos diciendo al procesador que realice la operación de lectura, modificación y escritura en un solo paso indivisible a nivel de bus de memoria, sin necesidad de que el runtime de Go gestione bloqueos de software.

Utilizamos estas primitivas cuando necesitamos una latencia mínima en rutas críticas de ejecución, como contadores de métricas en un proxy de red, flags de estado para el apagado de servicios o la actualización de configuraciones que se leen millones de veces pero se cambian rara vez. Si intentas usar atomic para coordinar una lógica compleja que involucra múltiples variables, romperás la consistencia de tu estado; la atomicidad es solo para una dirección de memoria a la vez.

El error más grave ocurre cuando intentas construir una operación compuesta usando múltiples llamadas atómicas por separado. Si realizas un Load y luego un Store basado en ese valor, la atomicidad se pierde en el intervalo entre ambas llamadas, permitiendo que otra goroutine intervinya.

package main

import (
	"fmt"
	"sync"
	"sync/atomic"
)

// Config representa una configuración de sistema que cambia poco.
type Config struct {
	Threshold int
	Enabled   bool
}

// Monitor gestiona métricas y estado sin necesidad de mutex.
type Monitor struct {
	// Usamos tipos atómicos modernos [disponible desde Go 1.19]
	// que encapsulan la gestión de punteros y aseguran la alineación
	// de memoria necesaria para instrucciones atómicas en todas las arquitecturas.
	hits   atomic.Int64
	status atomic.Int32 // 0: Parado, 1: Corriendo, 2: Apagado
	config atomic.Value // Almacena un *Config
}

func (m *Monitor) Increment() {
	// Add incrementa el valor de forma indivisible a nivel de hardware.
	m.hits.Add(1)
}

func (m *Monitor) GetConfig() *Config {
	// Load recupera el valor actual. Es extremadamente rápido porque
	// no hay contención de bloqueo.
	return m.config.Load().(*Config)
}

func (m *Monitor) TryShutdown() bool {
	// CompareAndSwap (CAS) es el corazón del lock-free programming.
	// Dice: "Si el valor actual es 1, cámbialo a 2".
	// Si otra goroutine cambió el estado justo antes, esto devolverá false.
	return m.status.CompareAndSwap(1, 2)
}

func main() {
	m := &Monitor{}

	// Inicialización de la configuración y el estado.
	m.config.Store(&Config{Threshold: 100, Enabled: true})
	m.status.Store(1)

	var wg sync.WaitGroup
	numGoroutines := 100
	iteraciones := 1000

	// Simulamos alta contención en el contador.
	for i := 0; i < numGoroutines; i++ {
		wg.Add(1)
		go func() {
			defer wg.Done()
			for j := 0; j < iteraciones; j++ {
				m.Increment()
			}
		}()
	}

	wg.Wait()

	// Verificación de resultados.
	finalHits := m.hits.Load()
	currentStatus := m.status.Load()
	conf := m.GetConfig()

	fmt.Printf("Hits totales: %d (esperado: %d)\n", finalHits, numGoroutines*iteraciones)
	fmt.Printf("Estado actual: %d\n", currentStatus)
	fmt.Printf("Configuración: %+v\n", conf)

	// Intento de apagado controlado.
	if m.TryShutdown() {
		fmt.Println("Sistema apagado exitosamente mediante CAS.")
	} else {
		fmt.Println("El apagado falló o ya estaba en proceso.")
	}
}

Desglose de la implementación

En el ejemplo, Monitor utiliza tres técnicas distintas para evitar el uso de un sync.Mutex:

1. Contadores de alta contención: La variable hits utiliza atomic.Int64. Cuando llamamos a m.hits.Add(1), la CPU ejecuta una instrucción que bloquea el acceso a ese bus de memoria solo durante ese ciclo de instrucción, permitiendo que miles de goroutines incrementen el valor con una latencia órdenes de magnitud menor que un mutex.

2. Patrones Read-Mostly-Write-Rarely: Para config, utilizamos atomic.Value. Este es ideal para objetos de configuración que se leen constantemente. m.config.Load() no bloquea a las demás goroutines; simplemente obtiene una copia del puntero actual. Esto evita que las lecturas se detengan cuando una goroutine está actualizando la configuración.

3. Transiciones de estado con CAS: El método TryShutdown usa CompareAndSwap. Esto es crucial para evitar “condiciones de carrera de comprobación” (check-then-act). Si dos goroutines intentan apagar el sistema al mismo tiempo, solo una recibirá true porque la primera que llegue cambiará el valor de 1 a 2, haciendo que la segunda comparación falle.

El error frecuente

Un error clásico es intentar implementar una lógica condicional compleja usando solo llamadas atómicas separadas. Fíjate en este código erróneo:

// ERROR: Esto NO es atómico
func (m *Monitor) InsecureDecrement() {
    // Error: La lectura y la escritura están separadas.
    // Una goroutine puede leer '10', otra puede leer '10',
    // ambas restan y ambas guardan '9'. Se perdió un decremento.
    val := m.hits.Load()
    m.hits.Store(val - 1)
}

Para que una operación sea realmente atómica, toda la lógica de decisión debe ocurrir dentro de una primitiva de hardware, como un bucle for que reintente la operación si el CompareAndSwap falla, o mediante el uso de funciones compuestas como Add.

N° 147