ایک data race اس وقت ہوتا ہے جب دو یا زیادہ goroutines ایک جیسی میموری کو بیک وقت access کریں، کم از کم ایک access write ہو، اور ان کے درمیان کوئی synchronization نہ ہو۔ نتیجہ undefined behavior ہے — corrupted ڈیٹا، crashes، یا غلط نتائج جو بیچ بیچ میں ظاہر ہوتے ہیں۔ Go ایک built-in race detector فراہم کرتا ہے انہیں تلاش کرنے کے لیے۔
// ❌ DATA RACE — multiple goroutines write the same variable without synchronization
func main() {
counter := 0
var wg sync.WaitGroup
for i := 0; i < 1000; i++ {
wg.Add(1)
go func() {
defer wg.Done()
counter++ // RACE: read-modify-write, multiple goroutines at once
}()
}
wg.Wait()
fmt.Println(counter) // often NOT 1000 — updates are lost due to the race
}
counter++ read-modify-write ہے (تین مراحل)۔ جب goroutines interleave کریں، updates ایک دوسرے کو overwrite کرتے ہیں، اس لیے final count unpredictable ہے۔ نتیجہ runs کے درمیان مختلف ہوتا ہے — races کی خطرناک نوعیت۔
go run -race main.go # run with race detection enabled
go test -race ./... # run tests with the race detector (best practice in CI)
go build -race # build a race-detecting binary
The race detector reports each race it observes:
==================
WARNING: DATA RACE
Write at 0x... by goroutine 7: main.main.func1() main.go:12
Previous read at 0x... by goroutine 6: ...
==================
Race detector runtime پر memory accesses کو instrument کرتا ہے اور بالکل رپورٹ کرتا ہے کہ ریس کہاں ہوتی ہے (conflicting accesses اور ان کے goroutines/lines)۔ یہ Go کے سب سے اہم tools میں سے ایک ہے — اپنے tests کو -race کے ساتھ باقاعدگی سے چلائیں (خاص طور پر CI میں) races کو production سے پہلے پکڑنے کے لیے۔
// Fix 1: protect with a mutex
var mu sync.Mutex
mu.Lock(); counter++; mu.Unlock()
// Fix 2: use atomic operations (lock-free, for simple values)
import "sync/atomic"
var counter int64
atomic.AddInt64(&counter, 1) // atomic — no race
// Fix 3: don't share — use channels to pass ownership
results := make(chan int)
// each goroutine sends its result; one goroutine aggregates
Fixes synchronization tools ہیں: ایک mutex access کو serialize کرنے کے لیے، atomic operations سادہ counters کے لیے، یا channels memory sharing سے بچنے کے لیے۔
✗ NON-DETERMINISTIC — may work in testing, fail in production (timing-dependent)
✗ Hard to reproduce — depends on goroutine scheduling, load, hardware
✗ UNDEFINED behavior — not just wrong values; can corrupt data or crash
✗ Often invisible without the race detector — no error, just subtly wrong results
Data races concurrent Go میں سب سے خطرناک اور سب سے مشکل سے debug ہونے والے bugs میں سے ہیں — اور Go کی concurrency-heavy design انہیں حقیقی خطرہ بناتی ہے۔
وہ خطرناک ہیں کیونکہ وہ non-deterministic ہیں: ایک race والا code تمام tests میں pass ہو سکتا ہے اور light load کے تحت ٹھیک کام کر سکتا ہے، پھر production میں concurrent load کے تحت intermittently fail ہو سکتا ہے، corrupted data، غلط نتائج، یا crashes پیدا کر سکتا ہے جو دوبارہ پیدا کرنا تقریباً ناممکن ہے۔
دقیق تعریف کو سمجھنا (shared memory تک concurrent access کم از کم ایک write اور کوئی synchronization کے ساتھ)، یہ سمجھنا کہ counter++ جیسا innocent-looking code بھی race کرتا ہے، اور fixes کو جاننا (mutex، atomic، channels) صحیح concurrent Go لکھنے کے لیے ضروری ہے۔
اہم بات یہ ہے، Go کا built-in race detector (-race) لازمی tool ہے — tests کو اس کے ساتھ چلانا (بہتری سے CI میں) races کو پکڑتا ہے جو ورنہ نظر انداز ہو جاتے ہیں۔
Race detection اور prevention میں مہارت حاصل کرنا production-grade concurrent Go کے لیے ایک بنیادی skill ہے اور language میں سب سے اہم advanced topics میں سے ایک ہے، کیونکہ concurrency correctness بالکل وہی جگہ ہے جہاں Go programs اکثر ناکام ہوتے ہیں۔
تفصیلی جوابات کے ساتھ IT انٹرویو سوالات کی ایک لائبریری — جونیئر سے سینئر تک۔
عطیہ دیں