your code holds a lock for microseconds. other processes can still wait tens of milliseconds for it. the scheduler doesn't know a process holds a lock. if it gets preempted in the middle of the critical section, it just sits in the run queue with the lock. everyone waiting stays stuck. spinlock waiters keep burning cpu the whole time. the simple fix helps most. keep the critical section tiny. do the slow work first, take the lock only for the final update.

the kernel doesn't translate your addresses. the mmu does. the mmu is hardware inside the cpu. on every load and store it turns a virtual address into a physical one. the kernel just writes the page tables in memory and tells the cpu where they are. on x86-64 that's the cr3 register. so two processes can both use 0x400000 and never see each other. each has its own page tables, so the same address lands on different ram.

-I, -L and -l look alike, but they talk to different tools. -I is for the preprocessor. it says where your headers are. miss it and you get "No such file or directory". -L and -l are for the linker. -L says which folder to search, -l says which library. -lsfml-graphics means find libsfml-graphics.so. miss those and the code compiles fine, then dies with undefined reference.

two nodes read a counter at 5. both add 1. both write 6. one increment is gone. a g-counter stops sharing one number. each node only bumps its own slot. A: 3, B: 2 becomes A: 4, B: 3. the value is the sum, 7. when nodes sync they take the max of each slot, so getting the same update twice changes nothing. you build this yourself in the counter track on build distributed systems.

in sql server, a plain SELECT can get stuck behind an UPDATE. under the default read committed, the reader asks for a shared lock on the row. the writer holds an exclusive lock until it commits. so the select just waits. turn on READ_COMMITTED_SNAPSHOT and the select reads the last committed version of the row instead. readers and writers stop blocking each other. still no dirty reads. the cost is the version store, which can grow a lot under heavy writes.

x86-64 has no 128-bit general purpose registers. but __int128 still works in gcc. the trick is one instruction. mul takes two 64-bit values and puts the full 128-bit product in rdx:rax. high half in rdx, low half in rax. so a 128-bit multiply compiles to one mul, two imul and two adds. a 128-bit add is just add, then adc for the carry.

your read() can fail even when nothing is wrong. if a signal shows up while it's blocked waiting for data, the kernel wakes it, runs your handler, and read returns -1 with errno = EINTR. no data was lost. the call just got cut short. so either loop and call it again, or set SA_RESTART in sigaction and the kernel restarts it for you.

http/2 sends all your requests over one tcp connection. that's the win, and also the catch. tcp hands bytes to the app in order. if one packet is lost, everything after it waits for the resend, even frames from other streams. so one dropped packet from an image can stall your css and your api call too. http/3 runs on quic over udp. each stream keeps its own order, so a loss only blocks that one stream.

you can malloc 5 bytes, write to the 6th one, and the program can still run like nothing happened. memory bugs often don't crash. they corrupt something quietly and wait. two ways to catch them: • valgrind runs your binary as is and checks every memory access. no recompile, but 10 to 50x slower • asan: build with -fsanitize=address. the compiler adds the checks and tracks memory in a shadow map. about 2 to 3x slower

Launch pricing for LowLevelCraft ends 31 October. 479+ hands-on tasks: C, assembly, compilers, OS, networking, storage, security. Real code, real tests, in the browser. Lifetime includes Interview Prep. After the 31st, it's list price.