channels-க்குப் பதிலாக sync package-ஐ எப்போது பயன்படுத்துவீர்கள்?

Question

Accepted Answer

Go ஆனது concurrency safety-க்கு இரண்டு அணுகுமுறைகளை வழங்குகிறது: **channels** ("share memory by communicating") மற்றும் **`sync` package** (பகிரப்பட்ட memory-ஐ நேரடியாகப் பாதுகாக்க mutexes/locks). Go-வின் channel-முதன்மை தத்துவம் இருந்தபோதிலும், பகிரப்பட்ட state-ஐ பாதுகாப்பதற்கு sync primitives பெரும்பாலும் எளிமையான, மிகவும் திறமையான தேர்வாக இருக்கின்றன.

## 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 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` ஆனது concurrent 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 vs 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" என்பது ஒரு வழிகாட்டுதல், dogma அல்ல.** பகிரப்பட்ட state-ஐ வெறுமனே பாதுகாப்பதற்கு, logic-ஐ channels-ஆக திருகுவதைவிட ஒரு mutex தெளிவானதும் திறமையானதுமாகும்.

## இது ஏன் முக்கியம்

channels-க்குப் பதிலாக `sync` package-ஐ எப்போது பயன்படுத்துவது என்பதை அறிவது, Go concurrency முதிர்ச்சியின் ஒரு முக்கிய அறிகுறியாகும்.

Go channels-ஐ ஊக்குவிக்கிறது ("share memory by communicating") என்றாலும், இது ஒரு வழிகாட்டுதலே — மேலும் ஒரு எளிய **mutex** தெளிவாகவும் வேகமாகவும் இருக்கும் இடத்தில் channels-ஐ திணிப்பது ஒரு பொதுவான தவறாகும்.

`sync` package ஆனது **பகிரப்பட்ட state-ஐ பாதுகாப்பதற்கான** (counters, caches, maps) சரியான, idiomatic கருவியாகும்: exclusive access-க்கு mutexes, read-heavy data-க்கு `RWMutex`, goroutines-க்காக காத்திருக்க `WaitGroup`, one-time initialization-க்கு `Once`, மற்றும் specialized cases-க்கு `atomic`/`sync.Map`.

channels ஆனவை *communication மற்றும் coordination*-இல் சிறந்து விளங்குகின்றன, அதேசமயம் sync primitives ஆனவை *பகிரப்பட்ட memory-ஐ காவல் காப்பதில்* சிறந்து விளங்குகின்றன என்பதைப் புரிந்துகொண்டு — dogmatic ஆக channels-ஐ பயன்படுத்துவதற்குப் பதிலாக பொருத்தமான கருவியைத் தேர்ந்தெடுப்பது — எளிமையான, மிகவும் திறமையான, மிகவும் சரியான concurrent code-க்கு வழிவகுக்கிறது.

இந்தத் தீர்ப்பாற்றலே அனுபவம் வாய்ந்த Go developers-ஐ வேறுபடுத்துகிறது மற்றும் ஒரு அடிக்கடி வரும் மேம்பட்ட interview தலைப்பாகும்.