• Johnny's avatar
    fix: resolve data races in store tests with atomic operations · db57f445
    Johnny authored
    Fix all data races detected by -race flag in parallel store tests.
    
    Problems fixed:
    1. TestMain not propagating exit code
       - Was: m.Run(); return
       - Now: os.Exit(m.Run())
    
    2. Data races on global DSN variables
       - mysqlBaseDSN and postgresBaseDSN written in sync.Once
       - Read outside Once without synchronization
       - Race detector: write/read without happens-before relationship
    
    3. Data races on container pointers
       - mysqlContainer, postgresContainer, testDockerNetwork
       - Same pattern: write in Once, read in cleanup
    
    Solution: Use atomic operations
    - atomic.Value for DSN strings (Store/Load)
    - atomic.Pointer for container pointers (Store/Load)
    - Provides proper memory synchronization
    - Race-free reads and writes
    
    Why sync.Once alone wasn't enough:
    - sync.Once guarantees function runs once
    - Does NOT provide memory barrier for variables written inside
    - Reads outside Once have no synchronization with writes
    - Race detector correctly flags this as violation
    
    Technical details:
    - atomic.Value.Store() provides release semantics
    - atomic.Value.Load() provides acquire semantics
    - Guarantees happens-before relationship per Go memory model
    - All 159 parallel tests can safely access globals
    
    Impact:
    - Tests now pass with -race flag
    - No performance degradation (atomic ops are fast)
    - Maintains parallel execution benefits (8-10x speedup)
    - Proper Go memory model compliance
    
    Related: Issues #2, #3 from race analysis
    db57f445
containers.go 13.3 KB