Tưởng exec chỉ là nhảy vào chương trình mới nên tức thì? Tôi đo: execve tốn 45,6µs cho binary tĩnh (nạp ELF, ánh xạ segment), và 73,5µs cho binary động — chậm 1,61 lần dù file nhỏ hơn 12 lần, vì trình liên kết ld.so phải phân giải symbol trước main. Nhỏ trên đĩa không bằng nhanh lúc chạy.
Tưởng cứ hàng đợi lớn (hoặc vô hạn) để không mất việc, và producer đẩy càng nhanh càng tốt? Tôi đo: producer nhanh hơn consumer với hàng đợi vô hạn thì độ sâu chạm 5,46 triệu item, latency nổ lên 270ms, bộ nhớ phình mãi; đặt hàng đợi có chặn thì producer tự ghìm về tốc độ consumer, latency có trần, bộ nhớ gần 0. Backpressure là khác biệt giữa ổn định và sụp đổ.
Tưởng kiểm null rồi khóa rồi kiểm lại là đủ, và DCL chỉ là mẹo tránh khóa? Tôi đo: fast-path đọc atomic không khóa nhanh 314 lần always-lock — nhưng DCL đúng bắt buộc có rào bộ nhớ (acquire/release), thiếu nó luồng khác thấy con trỏ đã publish mà object chưa khởi tạo xong. Một bug ẩn kỹ tới mức Java mất nhiều năm mới thừa nhận.
Tưởng biến chung đọc/ghi bình thường vẫn chạy được, và volatile là đủ cho đa luồng? Tôi đo: hai luồng tăng một biến non-atomic mất ~50% cập nhật, đọc cờ chung non-atomic bị -O2 hoist thành treo vĩnh viễn — chỉ atomic mới đảm bảo. Và trớ trêu, -O2 gập mất cuộc đua ngay trong phép đo về nó.
Tưởng seqlock chỉ là rwlock nhanh hơn, và reader luôn đọc được ngay? Tôi đo: reader seqlock chỉ đọc một bộ đếm nên scale gần tuyến tính (nhanh 862 lần rwlock ở 8 luồng) và không bao giờ thấy snapshot rách — nhưng phải đọc lại khi có writer, ghi dồn thì retry tới 12,7 lần mỗi đọc. Mỗi công cụ đồng bộ là một đổi chác riêng, không phải bậc thang nhanh dần.
Tưởng CAS thành công nghĩa là không ai đụng vào, và lock-free cứ CAS là an toàn? Tôi ép giá trị đổi A rồi B rồi A lại giữa lúc đọc và lúc CAS: CAS vẫn thành công dù ngăn xếp đã hỏng — đó là ABA. Versioned CAS bắt được tận gốc, và đo ra chỉ đắt hơn 1%.