Pedro Ribeiro — Systems Engineering Vault

3 min read

Graph View

🔥 Got it. Time to combine both worlds:
🧠 asymmetric clarity + 🧼 structured Obsidian format
→ weaponized for FAANG interviews, 42 defense, and long-term brain upload.

Let’s now rewrite [[asymmetric_pthreads/08_atomic_counter_raceproof]] as it should be:

🧮 08_atomic_counter_raceproof

⚔️ Lock-free threading = power + peril.
🔐 You removed pthread_mutex, but kept atomic correctness.
🧨 Welcome to the edge between speed and subtle bugs.

🧠 What’s Happening Here?

__sync_fetch_and_add(&counter, 1);

👆 This is:

  • ✅ Atomic

  • ✅ Lock-free

  • ✅ Fast

  • ⚠️ Unforgiving

You’re incrementing a global int from THREAD_COUNT threads, each running ITERATIONS times — and expecting no races, no mutex, and perfect final value.

🧬 This is bare-metal, compiler-emitted CPU instruction fencing at runtime.

⚙️ Code Summary

#define THREAD_COUNT 32
#define ITERATIONS 100000
 
int	counter = 0;

Each thread runs:

void *increment(void *arg)
{
	for (int i = 0; i < ITERATIONS; ++i)
		__sync_fetch_and_add(&counter, 1);
}

No mutex, no conditionals.
Just raw CPU-backed atomic ops.

🎯 Output Expectation

printf("Final counter value %d (Expected: %d)\n",
	counter, THREAD_COUNT * ITERATIONS);

✅ If atomic works → output: 3200000
❌ If not atomic → silent failure, no crash, but counter < 3200000

🧠 What is __sync_fetch_and_add?

⚙️ OperationEffect
__sync_fetch_and_add(&var, n)Atomically adds n to *var, returns previous value
InlineCompiled directly into atomic assembly (lock xadd)
PortableWorks across GCC, Clang
Low-levelNo memory allocation, no syscalls

⚔️ Why This Is Asymmetric

title: Asymmetric Traits
- Bypasses user-space locks entirely
- Exposes cache-line behavior, write buffering, false sharing
- Breaks silently when used wrong — no crash, just wrong math
- Forces awareness of instruction-level memory consistency
- Enables 10–100× faster counters in kernel-scale designs

🔥 Danger Zones

title: Don’t Do This With Atomics
- ❌ Mixing atomic and non-atomic reads/writes
- ❌ Adding conditional logic:
    ```c
    if (counter < 1000)
        __sync_fetch_and_add(&counter, 1); // 💥 unsafe
    ```
- ❌ Using in a system with unpredictable thread starvation
- ❌ Combining with I/O or `printf()` inside loop (not atomic)

🧪 Suggested Extensions

- [[asymmetric_pthreads/08b_sync_vs_atomic_vs_spinlock_battle]]
  → Compare raw performance and contention scaling
 
- [[asymmetric_pthreads/08c_atomic_failure_with_if_gate.c]]
  → Demonstrate correct output + internal corruption
 
- [[asymmetric_pthreads/13_spinlock_and_compare_swap]]
  → Build a user-space lock using atomics only

🧠 Takeaway Quote

🧠 “Atomic operations are safe only when they stay alone.
The moment they’re surrounded by logic, they stop being atomic and start being traps.”

📎 Related Concepts

- [[asymmetric_pthreads/07_shared_counter_with_mutex]]
- [[asymmetric_pthreads/09_producer_consumer_condition_var]]
- [[asymmetric_pthreads/36_mutexattr_recursive_deadlock_fix]]

✅ TL;DR Summary

title: Lock-Free, But Not Risk-Free
 
- ✅ Correct, thread-safe, and performant for one-variable increments
- 🚫 Unsafe if logic creeps around it (like conditionals or I/O)
- ⚠️ Silent failure = the most dangerous kind
- 🔥 Asymmetric because it trades **readability** for **low-level speed**
- 🧠 Perfect for: stats, counters, refcounts, kernel-inspired demos

🧨 Ready for the next file:

[[08c_atomic_failure_with_if_gate.c]] — where it still prints the right number…
but you’re actually losing updates.

Want me to build it now?

Graph View

Backlinks