آپ channels کی جگہ sync package کب استعمال کرتے ہیں؟

Question

Accepted Answer

Go بیک وقت محفوظ رہنے کے دو طریقے پیش کرتا ہے: **channels** ("memory کو communicate کے ذریعے شیئر کریں") اور **`sync` package** (mutexes/locks براہ راست شیئر شدہ memory کی حفاظت کے لیے)۔ Go کی channel-first فلسفہ کے باوجود، sync primitives اکثر shared state کی حفاظت کے لیے سادہ تر اور زیادہ موثر انتخاب ہیں۔

## sync.Mutex — lock کے ساتھ shared state کی حفاظت کریں

```go
type Counter struct {
    mu    sync.Mutex
    count int
}

func (c *Counter) Increment() {
    c.mu.Lock()           // acquire the lock — only one goroutine at a time past here
    defer c.mu.Unlock()    // release on return (defer ensures it always happens)
    c.count++              // safe — protected critical section
}
```

ایک `Mutex` یقینی بناتا ہے کہ ایک وقت میں صرف ایک goroutine محفوظ شدہ ڈیٹا تک رسائی حاصل کرے، data races سے بچاتے ہوئے۔ `Lock()`/`defer Unlock()` pattern idiomatic ہے۔

## sync.RWMutex — متعدد readers یا ایک writer

```go
type Cache struct {
    mu   sync.RWMutex
    data map[string]string
}
func (c *Cache) Get(key string) string {
    c.mu.RLock()           // READ lock — multiple readers allowed concurrently
    defer c.mu.RUnlock()
    return c.data[key]
}
func (c *Cache) Set(key, value string) {
    c.mu.Lock()            // WRITE lock — exclusive
    defer c.mu.Unlock()
    c.data[key] = value
}
```

`RWMutex` بیک وقت reads کی اجازت دیتا ہے لیکن exclusive writes کی — caches جیسے read-heavy ڈیٹا کے لیے بہترین۔

## دیگر sync primitives

```go
sync.WaitGroup           // wait for a group of goroutines to finish (Add/Done/Wait)
sync.Once                // run something EXACTLY once (lazy init, singletons)
  var once sync.Once
  once.Do(initialize)    // initialize runs only on the first call, ever
sync.Map                 // a concurrent map (specialized cases)
atomic.AddInt64(&n, 1)   // lock-free atomic operations for simple counters
```

## sync بمقابلہ channels کب استعمال کریں

```text
Use sync (Mutex/RWMutex/atomic) when:
  ✓ Protecting simple shared STATE (a counter, a cache, a map)
  ✓ The logic is "guard this data" — locking is simpler and faster than channels here
  ✓ Read-heavy data (RWMutex), one-time init (Once), simple counters (atomic)

Use channels when:
  ✓ COMMUNICATING/passing data between goroutines, signaling, coordinating
  ✓ Pipelines, worker distribution, ownership transfer
```

عملی قاعدہ: **"memory کو شیئر کر کے communicate نہ کریں" ایک رہنمائی ہے، نہ کہ ڈوگما۔** سادگی سے shared state کی حفاظت کے لیے، ایک mutex channels میں منطق کو مڑنے سے زیادہ واضح اور موثر ہے۔

## یہ اہم کیوں ہے

`sync` package کے استعمال کا موقع جاننا بمقابلہ channels کے ایک اہم نشانی ہے Go بیک وقت پختگی کی۔

جب کہ Go channels کو فروغ دیتا ہے ("memory کو communicate کے ذریعے شیئر کریں")، یہ ایک رہنمائی ہے — اور ایک عام غلطی یہ ہے کہ channels کو اس جگہ استعمال کرنا جہاں ایک سادہ **mutex** زیادہ واضح اور تیز ہو۔

`sync` package shared state کی حفاظت (counters, caches, maps) کے لیے صحیح، idiomatic tool ہے: mutexes exclusive access کے لیے، `RWMutex` read-heavy ڈیٹا کے لیے، `WaitGroup` goroutines کا انتظار کرنے کے لیے، `Once` ایک بار initialization کے لیے، اور `atomic`/`sync.Map` خصوصی cases کے لیے۔

yہ سمجھنا کہ channels *communication اور coordination* میں بہترین ہیں جب کہ sync primitives *shared memory کی حفاظت* میں بہترین ہیں — اور نتیجہ کے بجائے مناسب tool کا انتخاب کرنا — سادہ تر، زیادہ موثر، اور زیادہ درست بیک وقت code کی طرف لے جاتا ہے۔

yہ فیصلہ بالکل وہی ہے جو تجربہ کار Go developers کو علیحدہ کرتا ہے اور ایک بار بار advanced interview topic ہے۔