আপনি কখন channels এর পরিবর্তে sync প্যাকেজ ব্যবহার করেন?

Question

Accepted Answer

Go দুটি পদ্ধতি অফার করে concurrency safety এর জন্য: **channels** ("যোগাযোগের মাধ্যমে মেমরি শেয়ার করুন") এবং **`sync` প্যাকেজ** (mutexes/locks দ্বারা সরাসরি শেয়ার করা মেমরি সুরক্ষিত করুন)। Go এর channel-প্রথম দর্শন সত্ত্বেও, 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()` প্যাটার্ন idiomatic।

## 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` সমসাময়িক পড়ার অনুমতি দেয় কিন্তু একচেটিয়া লেখা — ক্যাশগুলির মতো read-heavy ডেটার জন্য আদর্শ।

## অন্যান্য 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
```

ব্যবহারিক নিয়ম: **"মেমরি শেয়ার করে যোগাযোগ করবেন না" একটি নির্দেশিকা, মতবাদ নয়।** সহজেই শেয়ার করা অবস্থা সুরক্ষিত করার জন্য, একটি mutex channels এ যুক্তি বিকৃত করার চেয়ে স্পষ্ট এবং আরও দক্ষ।

## এটি কেন গুরুত্বপূর্ণ

`sync` প্যাকেজ বনাম channels ব্যবহার করার সময় জানা Go concurrency পরিপক্বতার একটি মূল চিহ্ন।

যখন Go channels প্রচার করে ("যোগাযোগের মাধ্যমে মেমরি শেয়ার করুন"), এটি একটি নির্দেশিকা — এবং একটি সাধারণ ভুল হল channels জোর করা যেখানে একটি সাধারণ **mutex** আরও স্পষ্ট এবং দ্রুত হবে।

`sync` প্যাকেজ হল **শেয়ার করা অবস্থা রক্ষা করার** জন্য সঠিক, idiomatic টুল (কাউন্টার, ক্যাশ, ম্যাপ): একচেটিয়া অ্যাক্সেসের জন্য mutexes, read-heavy ডেটার জন্য `RWMutex`, goroutines এ অপেক্ষা করার জন্য `WaitGroup`, এক-বার শুরু করার জন্য `Once`, এবং বিশেষায়িত ক্ষেত্রের জন্য `atomic`/`sync.Map`।

বুঝতে পারা যে channels *যোগাযোগ এবং সমন্বয়ে* উৎকৃষ্ট যখন sync primitives *শেয়ার করা মেমরি রক্ষায় উৎকৃষ্ট* — এবং মতবাদভাবে channels ব্যবহার করার পরিবর্তে উপযুক্ত টুল নির্বাচন করা — সহজ, আরও দক্ষ, আরও সঠিক সমসাময়িক কোডের দিকে পরিচালিত করে।

এই বিচার হল ঠিক যা অভিজ্ঞ Go ডেভেলপারদের আলাদা করে এবং এটি একটি ঘন ঘন উন্নত সাক্ষাত্কার বিষয়।