channels के बजाय sync package का उपयोग कब करते हैं?

Question

Accepted Answer

Go concurrency सुरक्षा के लिए दो दृष्टिकोण प्रदान करता है: **channels** ("share memory by communicating") और **`sync` package** (shared memory को सीधे सुरक्षित रखने के लिए mutexes/locks)। 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 तक पहुँचे, जो data races को रोकता है। `Lock()`/`defer Unlock()` पैटर्न 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 data के लिए आदर्श।

## अन्य 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
```

व्यावहारिक नियम: **"Don't communicate by sharing memory" एक दिशानिर्देश है, हठधर्म नहीं।** केवल shared state की रक्षा के लिए, एक mutex logic को channels में मोड़ने की तुलना में स्पष्ट और अधिक कुशल है।

## यह क्यों महत्वपूर्ण है

channels बनाम `sync` package का उपयोग कब करना है यह जानना Go concurrency परिपक्वता का एक मुख्य संकेत है।

जबकि Go channels को बढ़ावा देता है ("share memory by communicating"), यह एक दिशानिर्देश है — और एक आम गलती channels को वहाँ ज़बरदस्ती लगाना है जहाँ एक सरल **mutex** स्पष्ट और तेज़ होता।

`sync` package **shared state की रक्षा** (counters, caches, maps) के लिए सही, idiomatic उपकरण है: exclusive access के लिए mutexes, read-heavy data के लिए `RWMutex`, goroutines की प्रतीक्षा के लिए `WaitGroup`, one-time initialization के लिए `Once`, और विशेष मामलों के लिए `atomic`/`sync.Map`।

यह समझना कि channels *communication और coordination* में उत्कृष्ट हैं जबकि sync primitives *shared memory की रक्षा* में उत्कृष्ट हैं — और हठधर्मिता से channels का उपयोग करने के बजाय उपयुक्त उपकरण चुनना — सरल, अधिक कुशल, अधिक सही concurrent code की ओर ले जाता है।

यह निर्णय ठीक वही है जो अनुभवी Go developers को अलग करता है और एक बार-बार आने वाला advanced interview विषय है।