તમે ચેનલોની જગ્યાએ sync પેકેજ ક્યારે વાપરો છો?

Question

Accepted Answer

Go સમવર્તિતા સુરક્ષા માટે બે અભિગમ આપે છે: **ચેનલો** ("મેમોરી શેર કરો કમ્યુનિકેટ કરીને") અને **`sync` પેકેજ** (શેર કરેલ મેમોરીને સીધી રીતે સુરક્ષિત કરવા માટે mutexes/locks)। Go ના ચેનલ-પ્રથમ ફિલોસોફી હોવા છતાં, sync આદિમો ઘણીવાર શેર કરેલ સ્થિતિ રક્ષણ માટે સરળ અને વધુ કાર્યક્ષમ પસંદ હોય છે।

## sync.Mutex — lock સાથે શેર કરેલ સ્થિતિ રક્ષણ કરો

```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` સમવર્તી રીડ્સને પરંતુ એક્સક્લુસિવ લેખનને મંજૂરી આપે છે — કેશ જેવા રીડ-ભારે ડેટા માટે આદર્શ છે।

## અન્ય sync આદિમો

```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 અને ચેનલો ક્યારે વાપરવા

```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 તર્ક કોચ્યુરનમાં ચેનલોમાં વધુ સ્પષ્ટ અને કાર્યક્ષમ છે।

## તે શા માટે મહત્વપૂર્ણ છે

`sync` પેકેજ બનામ ચેનલો ક્યારે વાપરવું તે જાણવું Go સમવર્તિતા પરિપક્વતાનું મુખ્ય સંકેત છે।

Go ચેનલોને પ્રોત્સાહિત કરે છે ("મેમોરી શેર કરીને કમ્યુનિકેટ કરો"), આ એક માર્ગદર્શન છે — અને એક સામાન્ય ભૂલ એ છે કે જ્યાં એક સરળ **mutex** વધુ સ્પષ્ટ અને ઝડપી હોય ત્યાં ચેનલો દબાણ કરવા।

`sync` પેકેજ **શેર કરેલ સ્થિતિ રક્ષણ** (કાઉન્ટર્સ, કેશ, મેપ્સ) માટે યોગ્ય, ઇડિયોમેટિક સાધન છે: એક્સક્લુસિવ ઍક્સેસ માટે mutexes, રીડ-ભારે ડેટા માટે `RWMutex`, goroutines પર રાહ જોવા માટે `WaitGroup`, એક વખતની ઇનિશિયલાઇઝેશન માટે `Once`, અને વિશેષ કેસો માટે `atomic`/`sync.Map`।

Chainels *કમ્યુનિકેશન અને કોઓર્ડિનેશન*માં શ્રેષ્ઠ છે જ્યારે sync આદિમો *શેર કરેલ મેમોરીને રક્ષણ*માં શ્રેષ્ઠ છે તે સમજવું — અને ડોગમેટિક રીતે ચેનલો વાપરવાને બદલે યોગ્ય સાધન પસંદ કરવું — સરળ, વધુ કાર્યક્ષમ, વધુ સાચું સમવર્તી કોડ તરફ દોરી જાય છે।

यह નિર્ણય બરાબર જે રીતે અનુભવી Go ડેવલપર્સને અલગ પાડે છે અને એક વારંવાર અદ્યતન ઇન્ટરવ્યુ વિષય છે।