sync पॅकेज वापरायचं कधी आहे channel ऐवजी?

Question

Accepted Answer

Go समवर्ती सुरक्षेसाठी दोन पद्धती देते: **channel** ("मेमरी साझा करून संवाद करणे") आणि **`sync` पॅकेज** (सामायिक मेमरी थेट संरक्षित करण्यासाठी mutex/लॉक). Go च्या channel-first तत्वज्ञानाच्या बावजूद, sync primitives सहसा सामायिक स्थिति संरक्षित करण्यासाठी सोपे आणि अधिक कार्यक्षम निवड असतात.

## sync.Mutex — लॉकसह सामायिक स्थिति संरक्षित करणे

```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 संरक्षित डेटा अ्‍ँक्सेस करू शकते याची खात्री करते, डेटा रेस टाळते. `Lock()`/`defer Unlock()` पॅटर्न मुहावरेदार आहे.

## sync.RWMutex — अनेक वाचक किंवा एक लेखक

```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` समवर्ती वाचन परवानगी देते पण केवळ लेखन — cache सारख्या वाचन-भारी डेटासाठी आदर्श.

## इतर 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 vs channel वापरायचं कधी

```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
```

व्यावहारिक नियम: **"मेमरी साझा करून संवाद करू नका" हा एक मार्गदर्शन आहे, शिद्दत नाही.** केवळ सामायिक स्थिति संरक्षित करण्यासाठी, mutex ला channel मध्ये तर्क वाकवण्यापेक्षा स्पष्ट आणि अधिक कार्यक्षम आहे.

## हे महत्वाचं का आहे

कधी `sync` पॅकेज वापरायचे हे जाणणे channel च्या विरुद्ध Go समवर्ती परिपक्वतेचे मुख्य संकेत आहे.

Go channel जाहिर करत असल्या ("मेमरी साझा करून संवाद करणे"), हे एक मार्गदर्शन आहे — आणि एक सामान्य चूक म्हणजे channel जेथे साधा **mutex** स्पष्ट आणि वेगवान असेल तेथे लाद करणे.

`sync` पॅकेज हे **सामायिक स्थिति संरक्षित करण्यासाठी** योग्य, मुहावरेदार साधन आहे (गणक, cache, नकाशे): एकमेव प्रवेशसाठी mutex, वाचन-भारी डेटासाठी `RWMutex`, goroutine च्या प्रतीक्षेसाठी `WaitGroup`, एकदा आरंभीकरणासाठी `Once`, आणि विशेष प्रकरणांसाठी `atomic`/`sync.Map`.

हे समजणे की channel *संवाद आणि समन्वयात* उत्कृष्ट आहेत तर sync primitives *सामायिक मेमरी गार्ड करण्यात* उत्कृष्ट आहेत — आणि पूर्वाग्रह असून channel वापरण्याऐवजी योग्य साधन निवडणे — सोपे, अधिक कार्यक्षम, अधिक योग्य समवर्ती कोडकडे नेले.

हा निर्णय अनुभवी Go डेव्हलपर्स ला वेगळे करतो आणि हा वारंवार मुख्य मुलाखत विषय आहे.