liveBook · Manning

Write starvation

As explained in Learn Concurrent Programming with Go

A starvation condition in which a writer is indefinitely or excessively delayed because readers continuously hold a shared resource.

Write starvation occurs when readers continuously hold a shared resource, preventing a writer from entering its critical section. A read-preferring readers–writer lock can leave the writer waiting indefinitely because new readers keep access flowing. section 5.1.4

Readers keep the writer waiting

Two goroutines repeatedly acquire a reader lock, sleep for one second, print “Read done,” and release it. The main goroutine later requests the writer lock, but output continues with “Read done” indefinitely and never reaches “Write finished.”

How Learn Concurrent Programming with Go covers it

How deep it goes
Explains the execution scenario and implements a write-preferring condition-variable lock, stopping short of broader fairness policies.
Examples
Uses two looping reader goroutines, a blocked main-goroutine writer, repeated output, and a write-preferring Go mutex.
What it assumes
Assumes readers–writer locks and mutexes, while defining starvation through a concrete goroutine execution.
What you can do after
Diagnose starvation and build a write-preferring readers–writer mutex with condition variables.
How it connects
Connects readers–writer locks, mutexes, condition variables, goroutines, and shared resources.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Learn Concurrent Programming with Go. The section links point to the parts of the book it draws on.