Đa nhiệm trong Ruby 3 với Guild

Tại Ruby Kaigi 2016, Koichi Sasada - nhà thiết kế của máy ảo Ruby hiện nay đề xuất một mô hình đa nhiệm mới trong Ruby 3.

Trong khi Ruby có một hệ thống đa luồng cho phép thực hiện đồng thời, thì MRI không cho phép thực hiện song song mã Ruby. Koichi nhìn những thách thức khác nhau của chạy Ruby trong song song gồm object mutation, xử lý tương tranh, và đồng bộ hóa tiến trình. Kết quả là một đề xuất cho một cơ chế đa nhiệm và song song mới gọi là Guild.

Mục tiêu đa nhiệm

Các mục tiêu được đặt ra cho Guild trong Ruby 3 là: để giữ lại khả năng tương thích với Ruby 2 cho phép xử lý song song xem xét lại global lock ngăn chặn thực hiện song song cho phép chia sẻ đối tượng nhanh chóng và cung cấp phương thức để chia sẻ mutation object.

Đa nhiệm trong Ruby hôm nay là khó khăn bởi vì các lập trình viên phải tự đảm bảo rằng các tiến trình không xảy ra tương tranh. cách phổ biến xung quanh vấn đề này liên quan đến việc sử dụ!

ng lock, như tiến trình của Ruby :: Mutex, mà phần nào giải quyết mục đích ban đầu của xử lý song song. Lock có xu hướng làm chậm chương trình, và Lock không được sử dụng đúng thậm chí có thể khiến chương trình đa nhiệm chạy chậm hơn so với chạy đơn lẻ đồng bộ.

Guild làm việc như thế nào

Lưu ý: Với sự cho phép của Koichi, tôi đã sao chép một số hình ảnh minh họa từ đề xuất của ông nhằm làm rõ các khái niệm.

Guild được thực hiện trong điều kiện của class Thread và class Fiber. Trong khi Thread cho phép đa nhiệm thi hành code theo schedule dưới sự điều khiển của hệ điều hành, Fiber cho phép đa nhiệm kết hợp với schedule thực hiện có thể được điều khiển bằng tay.

Guild được bao gồm ít nhất một thread mà lần lượt có ít nhất một Fiber. Thread từ Guild khác nhau có thể chạy song song trong khi Thread cùng một Guild không thể. Các đối tượng từ một Guild không thể đọc hoặc gửi thông điệp cho các đối tượng từ Guild khác. Các thread thuộc cùng một Guild không thể thực hiện song song bởi vì có một GGL (Giant Guild Khóa) đảm bảo rằng các thread trong một Guild sẽ thi hành tuần tự. Tuy nhiên, Thread từ Guild khác nhau có thể thực hiện song song.

Bạn có thể nghĩ về một chương trình 2.x Ruby như có một Guild duy nhất.

Sự giao tiếp giữa các Guild

Một object từ một Guild sẽ không thể đọc hay gửi thông điệp cho một mutable object từ một Guild khác, nhằm ngăn chặn việc hai đối tượng chạy song song thực hiện việc đọc và chỉnh sửa giá trị của đói phương.

Tuy nhiên, các guild có thể giao tiếp với nhau bằng cách sử dụng Guild :: Channel việc này cho phép sao chép hoặc di chuyển các object qua kênh Guild khác.

phương thức chuyển giao (đối tượng) Guild :: Channel sẽ gửi một bản deep copy của đối tượng đến một Guild đích.

Nó cũng có thể hoàn toàn di chuyển một đối tượng từ một Guild khác sử dụng Guild :: transfer_membership Channel (đối tượng).

Khi một object đã được chuyển giao cho một Guild mới, nó không còn được truy cập từ Guild ban đầu của nó, và bất kỳ nỗ lực để truy cập tới object đó sẽ trả về một lỗi.

Trong khi Guild không thể chia sẻ mutable object mà không cần sao chép trước đó hoặc chuyển giao với nhau, điều quan trọng cần lưu ý là đối tượng bất biến có thể được chia sẻ (đọc) qua Guild miễn là chúng đang "deep frozen", có nghĩa là mọi object chúng reference đều là bất biến(imutable).

Dưới đây là một ví dụ để phân biệt có thể thay đổi từ đối tượng bất biến:

Ưu điểm của Guild so với Thread

Với thread, rất khó khăn để tìm ra các object nào đang được chia sẻ là mutable object. Guild ngăn chặn việc sử dụng chúng hoàn toàn và thay vào đó chia sẻ imutable object dễ dàng hơn nhiều. Koichi đã lên kế hoạch cho "các cấu trúc dữ liệu đặc biệt" để chia sẻ đối tượng có thể thay đổi với Guild. Những cấu trúc này sẽ tự động cô lập code có thể thay đổi nhiều rủi ro.