Golang

The Search-Insert-Delete Problem The Search-Insert-Delete Problem extends the classic Readers-Writers problem with three different access patterns instead of two. It demonstrates how to coordinate multiple operation types with different compatibility requirements - a common challenge in database systems and data structures. The Scenario Three types of goroutines access a shared list: Searchers - Read the list without modifying it Inserters - Add new elements to the list Deleters - Remove elements from the list Compatibility rules: ...

File monitoring is a common requirement in many applications: watching for configuration changes, processing uploads, syncing directories, or building development tools. In this post, we’ll build a production-ready file monitoring service that tracks word counts across all files in a directory using Go’s powerful concurrency primitives. The Challenge Build a service that: Monitors a directory and all its subdirectories Counts words in all files in real-time Updates counts when files are modified, created, or deleted Processes multiple files concurrently Provides current statistics on demand Handles errors gracefully Why This Matters Real-time file monitoring powers many production systems: ...

The Writer Starvation Problem In the readers preference solution, we saw how continuous readers can starve writers. The writers preference solution fixes this by giving writers priority. Key idea: When a writer is waiting, no new readers are allowed to start, even if other readers are currently reading. Real-World Need for Writer Priority Some systems need writer priority: Databases with critical updates (billing, inventory) Real-time systems (sensor updates must not be delayed) Logging systems (log writes can’t be delayed) Configuration systems (updates must propagate quickly) Leader election (state changes need priority) The Solution Go’s sync.RWMutex uses readers preference, so we need to implement writer preference manually using additional synchronization: ...

From Unbounded to Bounded In the previous article, we explored the unbounded buffer pattern where the queue could grow infinitely. This works until you run out of memory! The bounded buffer adds a crucial constraint: maximum queue size. This introduces backpressure - when the buffer is full, producers must wait for consumers to catch up. Why Bounded Buffers Matter Bounded buffers appear everywhere in production systems: TCP sliding windows (flow control) HTTP/2 stream flow control (prevents overwhelm) Message queue limits (RabbitMQ, Kafka partition limits) Thread pool queues (bounded task queues) Rate limiters (token buckets with finite capacity) Circuit breakers (limit concurrent requests) The key benefit: Bounded buffers provide natural backpressure and prevent resource exhaustion. ...

Building production-grade services requires more than just functionality-they need resilience, graceful degradation, and the ability to handle failures without crashing. In this post, we’ll build a robust logging service that demonstrates these principles using Go’s context package and proper error handling. The Problem Imagine your application sends logs to a remote logging service. What happens when: The logging service is slow or unresponsive? Network issues cause delays? The logging service crashes entirely? Without proper safeguards, your entire application could hang, crash, or become unresponsive just because logging failed. Logging should never bring down your application. ...

The Sleeping Barber Problem The Sleeping Barber is a classic synchronization problem proposed by Edsger Dijkstra in 1965. It elegantly demonstrates resource management, waiting, and signaling in concurrent systems. The Scenario A barbershop has: 1 barber 1 barber chair N waiting room chairs The rules: If no customers, the barber sleeps When a customer arrives: If barber is sleeping → wake him up If barber is busy → sit in waiting room (if space available) If waiting room is full → leave When barber finishes a customer → check waiting room Real-World Applications This pattern appears in many systems: ...

The Classic Dining Philosophers Problem The Dining Philosophers problem is one of the most famous concurrency problems, introduced by Edsger Dijkstra in 1965. It beautifully illustrates the challenges of resource sharing and deadlock in concurrent systems. The Setup: Five philosophers sit around a circular table. Between each pair of philosophers is a single fork (5 forks total). Each philosopher needs two forks to eat - one from their left and one from their right. ...

The Elevator Problem The Elevator Problem is a classic scheduling and optimization challenge that models how multiple elevators coordinate to serve passengers efficiently. It demonstrates load balancing, scheduling algorithms, optimization trade-offs, and decentralized coordination. Unlike many concurrency problems, it focuses on real-time decision-making and multi-objective optimization. The Scenario A building has: N elevators moving between floors M floors Passengers arriving at random floors with random destinations Call buttons (up/down) on each floor Destination buttons inside each elevator The goals: ...

The Bully Election Algorithm The Bully Algorithm, proposed by Hector Garcia-Molina in 1982, is a classic leader election algorithm for distributed systems. It’s called “bully” because the highest-numbered process always wins and “bullies” the others into accepting it as leader. The Scenario A distributed system needs a coordinator: N nodes in a network Each node has a unique ID (priority) One node must be elected as leader When the leader fails, a new leader must be elected Rule: The node with the highest ID wins The protocol: ...

The Fairness Problem We’ve seen two extremes: Readers preference: Writers can starve Writers preference: Readers can starve The fair solution ensures no starvation - everyone gets served in the order they arrive. The Solution: FIFO Ordering Key idea: Use a queue to serve requests in arrival order. This prevents both reader and writer starvation. Arrival Order: R1, R2, W1, R3, R4, W2 Execution: R1+R2 → W1 → R3+R4 → W2 (batch) (excl) (batch) (excl) Consecutive readers can still batch together, but writers don’t get skipped! ...