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 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 đổ.
Chèn từng phần tử để dựng heap 'phải là' O(n log n). Nhưng đo dữ liệu ngẫu nhiên thì nó phẳng 2,3 thao tác/phần tử — cũng O(n). O(n log n) chỉ hiện ở ca xấu (chèn giảm dần): thao tác leo 16→22 theo log n. Heapify thì O(n) bất kể đầu vào. Và heap không sắp xếp — nó chỉ cho min rẻ. Tôi đo.
Tưởng thư viện chuẩn thread-safe nên gọi thoải mái từ nhiều luồng, và code không có khóa thì phải scale? Tôi đo: rand() có khóa ẩn khiến tổng throughput sụp từ 258 xuống 6,5 triệu op/s ở 2 luồng, 8 luồng vẫn chậm hơn 1 luồng — trong khi rand_r() cùng thuật toán scale 5,1 lần.
Tưởng chạy một lần mỗi bên rồi so là đủ để biết một thay đổi đồng thời có đáng? Tôi đo: một lần chạy trúng nhiễu (outlier 13ms) đảo ngược cả kết luận — nói padded chậm 2,9 lần trong khi thật ra nó nhanh 4,36 lần. Nhiễu chỉ cộng, không trừ — nên phải lặp và lấy min.
Tưởng CPU luôn chạy theo thứ tự mình viết, còn reorder bộ nhớ chỉ là lý thuyết trong sách? Tôi đo litmus store-buffer trên ARM: reorder xảy ra thật (11 ca trong 60 triệu vòng), rào dmb ish dập được về 0. Nhưng nó hiếm tới ~1 trên 5,5 triệu vòng — nên code sai vẫn qua sạch mọi test rồi nổ ở production.