Tưởng semaphore chỉ là mutex đếm, K càng lớn càng nhanh? Tôi đo: semaphore chặn CỨNG số luồng đồng thời ở đúng K (mutex chỉ là K=1), throughput tăng theo K rồi bão hòa ở K=8; và khác mutex, semaphore không có chủ sở hữu nên báo hiệu được giữa hai luồng khác nhau — thứ mutex không làm được.
Tưởng barrier rẻ, cứ thêm cho chắc? Tôi đo: mỗi rào tốn 8 tới 41 micro giây, tăng theo số luồng vì phải đánh thức cả N luồng; và rào chờ luồng chậm nhất mỗi pha — một luồng nặng gấp 4 trong tám làm cả tính toán 500 pha chậm 1,75 lần. Barrier khuếch đại mọi mất cân bằng tải.
Tưởng future/async tự động nhanh và rẻ? Tôi đo bằng C++: future.get() là một điểm đồng bộ chặn tới khi promise set, và std::async mặc định tạo một luồng mới cho mỗi task — chạy hai vạn task nhỏ bằng async chậm hơn tuần tự 1724 lần. Future tiện cho một kết quả, không phải phép màu song song.
Tưởng tối ưu đồng bộ là làm mỗi lần đồng bộ nhanh hơn, hoặc batch càng lớn càng tốt? Tôi đo: gộp lô để giảm SỐ LẦN đồng bộ đẩy throughput từ 32 triệu lên 64,6 tỉ ops/giây — 2000 lần; nhưng độ trễ mỗi item cũng tăng ~94 lần theo kích thước lô. Batch tối ưu là cân bằng, không phải cực đại.
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.