Là một lập trình viên yêu công nghệ, thích viết blog để chia sẻ kiến thức, kinh nghiệm lập trình và những điều thú vị trong thế giới tech.
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 cứ thêm #pragma omp parallel for lên mọi vòng là song song hóa được? Tôi đo vòng gộp sum += a[i]: parallel ngây thơ cho kết quả SAI, mất 90% cập nhật — không chậm mà sai thầm lặng; sửa bằng atomic thì đúng nhưng chậm 267 lần; chỉ reduction vừa đúng vừa nhanh. Nhận ra phụ thuộc trước khi song song.
Tưởng thêm lõi thì tăng tốc tỉ lệ, và code gần như song song hoàn toàn sẽ scale gần tuyến tính? Tôi đo: một phần tuần tự nhỏ chặn speedup rất mạnh — 25% tuần tự trần ở 4 lần dù bao nhiêu lõi, và thực tế còn dưới cả Amdahl vì chi phí ẩn. Muốn nhanh hơn phải cắt phần tuần tự, không phải đếm lõi.
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'.
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 write() xong là dữ liệu đã an toàn trên đĩa? Tôi đo: write() chỉ copy vào page cache (RAM) rồi trả về ngay — nhanh 7 lần so với ép lên đĩa bằng fsync, nhưng dữ liệu chưa bền, mất điện trước write-back là mất sạch. 'Đã ghi' và 'đã bền' là hai chuyện khác nhau.