Sequential processing performs work one step after another rather than allowing those operations to overlap. In a construction project, the second floor must follow the first, while a narrow access road may allow only one transport at a time. Such non-parallel work becomes a bottleneck: adding workers cannot remove the required ordered steps. section 1.6.1
In concurrent Go programs, a mutex deliberately creates a sequential region. Only one goroutine can execute the code between Lock and Unlock, so the lock should cover the shared-state update rather than unrelated network or processing work. section 4.1.2
Use sequential processing deliberately:
- Keep ordering constraints sequential when later work depends on earlier work. section 1.6.1
- Avoid holding a mutex during downloads or other long operations; protect only the shared update. section 4.1.2
- Expect scalability to flatten as the sequential portion grows, even when more processors or goroutines are added. section 1.6.1
A mutex that makes everything sequential
A letter-frequency program starts goroutines to download RFC documents, but locking at the beginning of CountLetters and unlocking at the end forces each download and count to finish before the next begins. Moving the lock around only frequency[cIndex] += 1 preserves concurrent downloading while serializing the shared update.
