Không có futex thì chẳng có ý nghĩa gì

(h4x0r.org)

4 điểm bởi GN⁺ 2025-08-21 | Chưa có bình luận nào. | Chia sẻ qua WhatsApp

Giáo trình The Art of Multiprocessor Programming bị cho là đáng tiếc khi không đề cập đến khái niệm futex
Futex là thành phần cốt lõi của đồng bộ hóa hiệu quả trong lập trình song song hiện đại, cho hiệu năng vượt trội so với các khóa dựa trên System V trước đây
Futex có cấu trúc tách riêng việc giành khóa với chờ/đánh thức, nhờ đó giảm các system call và overhead không cần thiết
Bài viết gồm các ví dụ và kỹ thuật tự triển khai nhiều primitive đồng thời như spinlock, mutex, khóa đệ quy dựa trên futex
Tác giả chỉ ra khoảng cách giữa học thuật và thực tiễn khi cuốn sách không đề cập đến các phương pháp đồng bộ hóa hiện đại thiết yếu trong công việc kỹ sư thực tế

Giới thiệu

Phil Eaton bắt đầu câu lạc bộ đọc sách về The Art of Multiprocessor Programming, 2nd Edition
Cuốn sách này được xem là một giáo trình có thẩm quyền trong lĩnh vực lập trình song song, nhưng tác giả cho rằng nó thiếu tính thực dụng trong nội dung
Đặc biệt, dù nhắm đến sinh viên năm cuối đại học và học viên cao học, sách lại không đề cập đến futex, một kỹ thuật đồng bộ hóa cốt lõi, nên bị phê phán

Futex là viết tắt của “fast user space mutex”, nhưng trên thực tế, thay vì là một mutex hoàn chỉnh, nó là primitive đồng bộ hóa được OS hỗ trợ để triển khai các loại khóa hiện đại
Trước đây, phần lớn khóa được triển khai dựa trên semaphore của System V IPC nên bị giới hạn về hiệu quả và khả năng mở rộng
Khi futex được đưa vào Linux năm 2002, nó cho thấy hiệu năng nhanh hơn 20–120 lần so với khóa System V trong môi trường 1000 tác vụ đồng thời
Các hệ điều hành khác như Windows (2012) và macOS (2016) cũng đưa vào các cơ chế tương tự
Ngày nay, các khóa trong thư viện hệ thống được dùng rộng rãi như pthreads đều sử dụng futex

Semaphore truyền thống gộp khóa và chờ lại với nhau, còn futex tách riêng việc giành khóa với chờ/đánh thức
Nhờ vậy có thể giảm độ trễ và system call không cần thiết; khi mở khóa mà chắc chắn không có thread nào đang chờ thì không cần vào kernel
Lệnh chờ (wait) của futex chỉ cho phép “chờ khi giá trị tại một địa chỉ bộ nhớ cụ thể đúng với trạng thái mong muốn”, đồng thời hỗ trợ timeout
Lệnh đánh thức (wake) của futex sẽ đánh thức số lượng thread mong muốn từ danh sách chờ nội bộ gắn với một địa chỉ bộ nhớ cụ thể
Việc bắt buộc kiểm tra giá trị thực tại địa chỉ bộ nhớ giúp tránh chờ vô ích khi trạng thái đã thay đổi

Vì futex là primitive cấp thấp, cần dùng kiểu dữ liệu atomic để xử lý các vấn đề về thứ tự thao tác bộ nhớ của compiler và phần cứng
Trên Linux, phải gọi trực tiếp system call futex bằng syscall; trên macOS, dùng giao diện __ulock (gần đây đã có thêm API dễ dùng hơn)
Về cơ bản, lệnh chờ futex trả về 0 khi thành công, và mã lỗi khi thất bại (ví dụ timeout)
Các phép toán cốt lõi dựa trên futex:
- h4x0r_futex_wait_timespec() : chờ khi giá trị kỳ vọng khớp, có thể áp dụng timeout
- h4x0r_futex_wake() : đánh thức 1 hoặc toàn bộ waiter

Dạng khóa đơn giản nhất, hoạt động chỉ bằng một bit duy nhất (atomic_fetch_or)
Nó lặp vô hạn (“spin”) cho đến khi lấy được khóa, nhưng trong tình huống tranh chấp cao sẽ lãng phí CPU, đồng thời có các vấn đề cấu trúc như mở khóa sai hoặc deadlock khi gọi đệ quy

Thông thường sẽ thử bằng spinlock trước, nếu thất bại sau một số lần nhất định thì chuyển sang futex để block hiệu quả
Nếu không có waiter thì có thể tránh system call không cần thiết, còn với waiter thì cũng giảm số lần gọi system call để đánh thức
Do chưa kiểm tra chặt chẽ quyền sở hữu hay xử lý đệ quy, nó được gọi là “unsafe”

Một bit biểu thị trạng thái khóa, phần còn lại dùng để đếm số waiter, nhằm giảm các system call đánh thức không cần thiết
Tuy vậy vẫn chưa xử lý quyền sở hữu hay đệ quy

Dùng giá trị pthread_t để theo dõi rõ ràng chủ sở hữu khóa và trạng thái, từ đó phát hiện lỗi unlock sai hoặc sử dụng đệ quy
Việc lấy khóa, mở khóa và quản lý waiter đều được kiểm soát bằng các phép toán atomic nghiêm ngặt

Bổ sung bộ đếm độ lồng (depth) theo từng thread, cho phép cùng một thread lấy khóa lồng nhau
Khi unlock thì depth giảm; nếu về 0 thì mới thực hiện unlock thật sự và đánh thức waiter
Mỗi thao tác đều được triển khai bằng phép toán atomic và kiểm tra quyền sở hữu nghiêm ngặt

Nếu thread đang giữ khóa bị kết thúc bất thường/chết, cần danh sách quản lý riêng, callback khi kết thúc và các cơ chế bổ sung khác để quản lý khóa
Khi dùng mutex chia sẻ giữa các tiến trình, cũng cần thêm các cân nhắc để quản lý thay đổi trạng thái
Khóa đọc-ghi POSIX (RW lock) không định nghĩa hành vi lồng đệ quy một cách thống nhất và còn khác nhau tùy triển khai, nên trên thực tế khó bảo đảm an toàn
Tác giả phê phán việc những vấn đề đồng thời thật sự quan trọng trong thực chiến như futex, khóa đệ quy, runtime bất đồng bộ... không được đưa vào chương trình học

The Art of Multiprocessor Programming thiên về góc nhìn lịch sử hoặc lý thuyết, nên không truyền tải đầy đủ tri thức thực hành quan trọng của lập trình song song hiện đại
Nếu không trình bày đúng mức các thành phần đồng bộ hóa cốt lõi như futex vốn thực sự vận hành trong hệ thống, điều đó có thể gây hại thực tế cho thế hệ học viên sau này
Tác giả nhấn mạnh sự cần thiết phải cập nhật các khái niệm mới và bổ sung nội dung thực dụng