ਤੁਸੀਂ channels ਦੀ ਥਾਂ `sync` ਪੈਕੇਜ ਕਦੋਂ ਵਰਤਦੇ ਹੋ?

Question

Accepted Answer

Go ਦੋ ਤਰੀਕੇ concurrency safety ਦੇ ਲਈ ਦਿੰਦਾ ਹੈ: **channels** ("share memory by communicating") ਅਤੇ **`sync` ਪੈਕੇਜ** (mutexes/locks ਜੋ ਸਾਂਝੀ memory ਨੂੰ ਸਿੱਧਾ ਸੁਰੱਖਿਅਤ ਕਰਦੇ ਹਨ)। Go ਦੇ channel-ਪਹਿਲੀ ਦਰਸ਼ਨ ਦੇ ਬਾਵਜੂਦ, sync primitives ਅਕਸਰ ਸਾਂਝੀ state ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਨ ਲਈ ਸਰਲ, ਵਧੇਰੇ ਕੁਸ਼ਲ ਚੋਣ ਹਨ।

## sync.Mutex — lock ਦੇ ਨਾਲ ਸਾਂਝੀ 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" ਇੱਕ ਦਿਸ਼ਾ ਨਿਰਦੇਸ਼ ਹੈ, ਹਠਧਰਮ ਨਹੀਂ।** ਸਾਂਝੀ state ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਨ ਲਈ, ਇੱਕ mutex channels ਵਿੱਚ logic ਨੂੰ ਟੇਢਾ ਕਰਨ ਨਾਲੋਂ ਵਧੇਰੇ ਸਪਸ਼ਟ ਅਤੇ ਕੁਸ਼ਲ ਹੈ।

## ਇਹ ਕੀ ਅਹਿਮ ਹੈ

`sync` ਪੈਕੇਜ ਅਤੇ channels ਕਦੋਂ ਵਰਤਣੇ ਹਨ, ਇਹ ਜਾਣਨਾ Go concurrency ਪੱਕਤਾ ਦੀ ਮੁੱਖ ਨਿਸ਼ਾਨੀ ਹੈ।

ਜਦੋਂ ਕਿ Go channels ਨੂੰ ਤਰਜੀਹ ਦਿੰਦਾ ਹੈ ("share memory by communicating"), ਇਹ ਇੱਕ ਦਿਸ਼ਾ ਨਿਰਦੇਸ਼ ਹੈ — ਅਤੇ ਇੱਕ ਆਮ ਗਲਤੀ ਉਹਨਾਂ ਥਾਵਾਂ ਤੇ channels ਨੂੰ ਮਜਬੂਰ ਕਰਨਾ ਹੈ ਜਿੱਥੇ ਇੱਕ ਸਾਧਾਰਨ **mutex** ਵਧੇਰੇ ਸਪਸ਼ਟ ਅਤੇ ਤੇਜ਼ ਹੋਵੇ।

`sync` ਪੈਕੇਜ **ਸਾਂਝੀ state** ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਨ ਲਈ ਸਹੀ, idiomatic ਸਾਧਨ ਹੈ (counters, caches, maps): mutexes exclusive access ਲਈ, `RWMutex` read-heavy data ਲਈ, `WaitGroup` goroutines ਦੇ ਇੰਤਜ਼ਾਰ ਲਈ, `Once` ਇੱਕ-ਵਾਰ initialization ਲਈ, ਅਤੇ `atomic`/`sync.Map` ਵਿਸ਼ੇਸ਼ ਮਾਮਲਿਆਂ ਲਈ।
ury ਕਰਨਾ ਕਿ channels *communication ਅਤੇ coordination* ਵਿੱਚ ਸ਼ਾਨਦਾਰ ਹਨ ਜਦੋਂ sync primitives *shared memory ਨੂੰ ਗਾਰਡ ਕਰਨੇ* ਵਿੱਚ ਸ਼ਾਨਦਾਰ ਹਨ — ਅਤੇ ਧਰਮ ਨਿਰਪੱਖ ਤੌਰ ਤੇ channels ਵਰਤਣ ਦੀ ਥਾਂ ਸੂਕਤ ਸਾਧਨ ਚੁਣਨਾ — ਸਰਲ, ਵਧੇਰੇ ਕੁਸ਼ਲ, ਵਧੇਰੇ ਸਹੀ concurrent code ਵੱਲ ਲਿਜਾਂਦਾ ਹੈ।

ਇਹ ਨਿਰਣਾ ਬਿਲਕੁਲ ਵਸ਼ ਹੈ ਜੋ ਅਨੁਭਵੀ Go ਡੈਵਲਪਰਾਂ ਨੂੰ ਵੱਖ ਕਰਦਾ ਹੈ ਅਤੇ ਅਕਸਰ ਉੱਨਤ ਸਾਖਾ ਤਵੀ ਵਿਸ਼ਾ ਹੈ।