Tưởng nhiều luồng thì luôn nhanh hơn, hay cứ đặt số luồng bằng số lõi? Tôi đo hai loại việc trái ngược: việc thuần CPU chững ở ~nproc (thêm luồng vô ích), còn việc chờ-bound thì tối ưu vượt xa nproc — 80 luồng trên 10 lõi vẫn cho throughput gấp 8 lần vì luồng ngủ không chiếm lõi. Không có số luồng vàng.
Tưởng thêm luồng thì xong nhanh hơn, khóa chỉ tốn đúng thời gian giữ khóa? Tôi đo: khóa một vùng tới hạn tí xíu với 2-8 luồng cho throughput sụp còn 0,09-0,27 lần so một luồng — lock convoy. Cái đắt là BÀN GIAO khóa (mỗi lần đánh thức ~8,5µs), không phải việc trong khóa; gom lô hồi phục 118 lần.
Tưởng khóa nhiều mutex thì thứ tự nào chẳng được, chạy thử thấy chạy là ổn? Tôi tái hiện deadlock thật: hai luồng khóa ngược thứ tự treo cứng — nhưng chạy đúng hàng nghìn vòng, treo ở thời điểm khác nhau mỗi lần. Thuốc là áp một thứ tự khóa toàn cục, hoặc trylock+backoff.
Tưởng không deadlock, không treo là ổn, và trylock tránh deadlock nên an toàn? Tôi đo: livelock chạy hết CPU mà phí 5 lần vì backoff đồng nhịp, và rwlock để dòng reader bỏ đói writer — đọc nhiều hơn ghi 30.000 lần, writer chờ tới 30ms. 'Không treo' không bằng 'mọi luồng đều tiến'.
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.