Operating Systems
When Sharing Became Dangerous
Why communication alone was never enough.
Operating SystemsSynchronizationSemaphoresMutexesRace Conditions
2. The Race Condition
You just observed the same program producing different results.
The hardware did not change.
The code did not change.
Only the execution order changed.
This phenomenon is known as a Race Condition.
Because a simple operation like Counter++ is not atomic, the CPU compiles it into three distinct operations:
1. Read: Load Counter from RAM into a local CPU register.
2. Increment: Add 1 to the local register value.
3. Write: Write the register value back to the RAM address.
If two cores interleave these instructions in time, they clash:
Interleaved Instruction Execution
TIME
PROCESS A
PROCESS B
RAM
T1
Read Counter (100)
-
100
T2
-
Read Counter (100)
100
T3
Increment & Write (101)
-
101
T4
-
Increment & Write (101)
101 (Lost Update)
3. Synchronization
To solve this clashing, the Kernel must enforce coordination rules. We call this Synchronization.
🛡️
Mutual Exclusion: A synchronization boundary that guarantees only one CPU core accesses a specific shared memory variable or peripheral address at a time.
4. Semaphore
A Semaphore is a Kernel-managed tool consisting of an integer counter and a blocked queue:
* Counting Semaphore: Manages a pool of multiple resources. Processes decrement the counter to acquire a resource and increment it to return it. If the counter is 0, the requesting process is blocked.
* Binary Semaphore: Restricted to 0 or 1, acting as an on/off gate.
5. EdgeCase: Counting Semaphore
Watch how a Counting Semaphore of capacity 2 manages access to a shared connection pool. If slots are full, processes wait automatically in the queue.
6. Mutex
A Mutex (Mutual Exclusion Lock) is a binary lock with ownership. Only the thread that locks it can unlock it.
In embedded architectures, this is critical. Writing to a physical peripheral register (like setting configuration registers on an EEPROM chip or flash block) must be performed by exactly one process without interruption. An interrupted register write would corrupt the hardware state.
7. EdgeCase: Mutex Lock
Watch Process 1 and Process 2 write to a single EEPROM. When Process 1 locks the Mutex, Process 2 is automatically suspended until Process 1 unlocks the resource.
8. Comparison
Choosing the correct synchronization boundary depends on the specific engineering requirement:
When should I use a Semaphore?
- Resource pools
- Producer–Consumer signalling
- Limited shared resources
Example:
• DMA channels
• Connection pools
• Task notifications
When should I use a Mutex?
- Exclusive ownership
- Protecting one critical resource
- Lock–Unlock ownership
Example:
• EEPROM
• SPI peripheral
• I²C bus
• Configuration file
Current Exploration
When Sharing Became Dangerous
