Hai fd tới cùng một file: tạo bằng dup thì chung offset (đọc fd1 dời luôn fd2, fd2 đọc tiếp 'FGHIJ'), mở hai lần thì offset độc lập (fd2 đọc lại 'ABCDE' từ đầu). Cùng 'hai fd một file', hành vi ngược nhau — biến ẩn là cách chúng ra đời. Đo bằng /proc/fdinfo.
Tưởng khóa luôn đắt, hoặc mutex bị giành thì mỗi thao tác tốn ~8,5µs vì luồng phải ngủ? Tôi đo tinh tế hơn: không tranh chấp chỉ 3,3ns (futex, không vào nhân), tranh chấp với vùng tới hạn ngắn chỉ ~25ns (spin + cache nảy), chỉ vùng tới hạn dài mới thật sự ngủ. Cái đắt là tranh chấp nhân độ dài vùng tới hạn, không phải việc khóa.
Tưởng atomic miễn phí, lock-free nên không bị tranh chấp, luôn nhanh hơn mutex nhiều lần? Tôi đo cả ba đều lệch: atomic không tranh chấp chỉ ~1,6ns (rẻ hơn mutex 2 lần, cùng bậc), fetch_add tranh chấp vẫn chậm 10 lần vì cache nảy, và vòng CAS 8 luồng chậm hơn cả mutex vì phải thử lại. Lock-free không phải contention-free.
Tưởng cond_wait thức dậy là điều kiện đã đúng, dùng if là đủ, và đánh thức gần như tức thì? Tôi đo: đánh thức tốn ~8,5µs (đúng một chuyển ngữ cảnh), busy-poll nhanh 245 lần nhưng đốt trọn một lõi, và spurious/lost wakeup bắt buộc phải while + mutex — bỏ một trong hai là mời một bug đua tranh không tài nào tái hiện.
200 luồng chiếm 1612 MB VSZ nhưng chỉ 1,6 MB RAM thật (8KB mỗi luồng) — ngăn xếp 8MB là ảo, cấp lười. Guard page dưới mỗi stack biến tràn thành SIGSEGV chính xác, độ sâu đệ quy tỉ lệ thẳng cỡ stack (8MB ≈ 7939 tầng). Và -O2 suýt biến đệ quy vô hạn thành vòng lặp, đo nhầm hoàn toàn.
Tưởng cứ đọc nhiều thì rwlock luôn nhanh hơn mutex? Tôi đo: với vùng tới hạn đọc cực ngắn, rwlock chậm hơn mutex 5,9 lần vì bộ đếm đọc là một ghi chung bị cache nảy; chỉ khi mỗi lần đọc đủ dài rwlock mới thắng 6,3 lần nhờ đọc thật sự song song. Điểm lật nằm ở độ dài đọc, không phải ở đọc-nhiều-hay-ít.