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%.
Tưởng đọc trong cấu trúc lock-free cũng phải đồng bộ như rwlock, và thu hồi bộ nhớ lock-free là miễn phí? Tôi đo: đọc kiểu RCU ghi ô riêng nên scale gần tuyến tính, nhanh 374 lần rwlock ở 8 luồng — nhưng cái 'miễn phí' đó được trả ở writer, phải chờ grace period rồi mới free. Tối ưu chỉ dời chi phí, không xóa.
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 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 throughput cao là hệ nhanh, và đo latency bằng trung bình là đủ? Tôi đo từng thao tác dưới tranh chấp: throughput và latency là hai thứ khác nhau có thể cùng tệ đi, và latency là một phân phối lệch — ở 8 luồng trung vị chỉ 125ns nhưng p99 vọt lên 32.292ns, gấp 258 lần. Trung bình giấu cái đuôi mà người dùng thật sự gặp.
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 đổ.