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 đổ.
Tưởng một cấu trúc chung với một khóa là đủ, hoặc càng nhiều shard càng tốt? Tôi đo: một khóa chung sụp từ 229 xuống 35,7 triệu op/s khi đông luồng, chia nhiều shard giúp throughput scale 3 lần — nhưng càng nhiều shard, tính tổng toàn cục càng đắt (65 nghìn shard mất 32,8µs). Sharding dời chi phí chứ không xóa.
Tưởng atomic là lock-free nên luôn rẻ, và luôn nhanh hơn mutex? Tôi đo: fetch_add trên một atomic chung 1,6ns khi một luồng nhưng 44ns khi tám luồng — đắt theo số luồng vì cùng nảy một dòng cache; CAS-loop tệ nhất (119ns); còn per-thread nhanh 96 lần. Lock-free nói về ngữ nghĩa, không về chi phí.