# Single Writer Principle

DevFeed: [Single Writer Principle](<https://devfeed.tech/articles/single-writer-principle-13617.md>)

Original publisher: [Read original article](<https://mechanical-sympathy.blogspot.com/2011/09/single-writer-principle.html>)

Author: Martin Thompson (noreply@blogger.com)

Published: 2011-09-22T14:24:00Z

Content type: tutorial

Language: en

Sources: [Mechanical Sympathy](<https://devfeed.tech/sources/mechanical-sympathy.md>)

Topics: [Scalability](<https://devfeed.tech/topics/scalability.md>), [Concurrency](<https://devfeed.tech/topics/concurrency.md>), [systems](<https://devfeed.tech/topics/systems.md>), [Operating system](<https://devfeed.tech/topics/operating-system.md>), [Kernel](<https://devfeed.tech/topics/kernel.md>), [cpu](<https://devfeed.tech/topics/cpu.md>)

Tags: [concurrency](<https://devfeed.tech/tags/concurrency.md>), [concurrency-control](<https://devfeed.tech/tags/concurrency-control.md>), [concurrent](<https://devfeed.tech/tags/concurrent.md>), [cpu](<https://devfeed.tech/tags/cpu.md>), [cycles](<https://devfeed.tech/tags/cycles.md>), [intel](<https://devfeed.tech/tags/intel.md>), [kernel](<https://devfeed.tech/tags/kernel.md>), [latency](<https://devfeed.tech/tags/latency.md>), [performance](<https://devfeed.tech/tags/performance.md>), [processor-affinity](<https://devfeed.tech/tags/processor-affinity.md>), [scalability](<https://devfeed.tech/tags/scalability.md>)

## AI overview

The article explains that contention among multiple writers is a major scalability limitation. It compares mutual exclusion, typically implemented with locks, with optimistic concurrency control, describing how contention can increase queuing, latency, and reduce throughput.

## Source excerpt

When trying to build a highly scalable system the single biggest limitation on scalability is having multiple writers contend for any item of data or resource. Sure, algorithms can be bad, but let's assume they have a reasonable Big O notation so we'll focus on the scalability limitations of the systems design. I keep seeing people just accept having multiple writers as the norm. There is a lot of research in computer science for managing this contention that boils down to 2 basic approaches. One is to provide mutual exclusion to the contended resource while the mutation takes place; the other is to take an optimistic strategy and swap in the changes if the underlying resource has not changed while you created the new copy. Mutual Exclusion Mutual exclusion is the means by which only one writer can have access to a protected resource at a time, and is usually implemented with a locking strategy. Locking strategies require an arbitrator, usually the operating system kernel, to get involved when the contention occurs to decide who gains access and in what order. This can be a very expensive process often requiring many more CPU cycles than the actual transaction to be applied to the business logic would use. Those waiting to enter the critical section, in advance of performing the mutation must queue, and this queuing effect (Little's Law) causes latency to become unpredictable and ultimately restricts throughput. Optimistic Concurrency Control Optimistic strategies involve taking a copy of the data, modifying it, then copying back the changes if data has not mutated in the meantime. If a change has happened in the meantime you repeat the process until successful. This repeating of the process increases with contention and therefore causes a queuing effect just like with mutual exclusion. If you work with a source code control system, such as Subversion or CVS, then you are using this algorithm every day. Optimistic strategies can work with data but do not work so wel