Khi nào nên sử dụng Actor Model?Khi nào một người nên sử dụng mô hình Diễn viên?
Chắc chắn không đảm bảo môi trường không có khóa chết.
diễn viên A có thể chờ đợi một tin nhắn từ B trong khi B chờ A.
Ngoài ra, nếu một diễn viên có đảm bảo thông điệp của nó được xử lý trước khi chuyển sang công việc tiếp theo của nó, nó sẽ phải gửi một tin nhắn và chờ tin nhắn "tin nhắn của bạn đã được xử lý" thay vì chặn đơn giản.
Sức mạnh của mô hình là gì?
Với một số vấn đề tương tranh, bạn sẽ tìm cách quyết định có nên sử dụng diễn viên hay không?
Trước tiên tôi sẽ xem xét để xác định vấn đề ... là động cơ chính là tăng tốc của lồng nhau cho vòng lặp hoặc đệ quy? Nếu vậy một cách tiếp cận dựa trên nhiệm vụ đơn giản hoặc phương pháp tiếp cận vòng lặp song song sẽ có khả năng làm việc tốt cho bạn (chứ không phải là diễn viên).
Tuy nhiên, nếu bạn có một hệ thống phức tạp hơn liên quan đến các phụ thuộc và điều phối trạng thái chia sẻ, thì cách tiếp cận diễn viên có thể giúp bạn. Cụ thể là thông qua việc sử dụng diễn viên và ngữ nghĩa thông điệp, bạn thường có thể tránh sử dụng khóa rõ ràng để bảo vệ trạng thái chia sẻ bằng cách thực sự tạo bản sao của trạng thái đó (thư) và phản hồi cho chúng.
Bạn có thể làm điều này khá dễ dàng với các vấn đề đồng bộ hóa cổ điển như các nhà triết học ăn uống và vấn đề về thợ cắt tóc đang ngủ. Nhưng bạn cũng có thể sử dụng 'diễn viên' để trợ giúp với các mẫu hiện đại hơn, tức là mặt tiền của bạn có thể là một diễn viên, chế độ xem và bộ điều khiển mô hình của bạn cũng có thể là các diễn viên giao tiếp với nhau.
Một điều khác mà tôi đã quan sát được là ngữ nghĩa diễn viên có thể học được bởi hầu hết các nhà phát triển và 'an toàn hơn' so với các đối tác bị khóa của họ. Điều này là do chúng nâng mức trừu tượng và cho phép bạn tập trung vào việc điều phối quyền truy cập vào dữ liệu đó thay vì bảo vệ tất cả các truy cập vào dữ liệu bằng các khóa. Ví dụ, hãy tưởng tượng rằng bạn có một lớp đơn giản với một thành viên dữ liệu. Nếu bạn chọn đặt khóa trong lớp đó để bảo vệ quyền truy cập vào thành viên dữ liệu đó thì mọi phương thức trên lớp đó sẽ cần phải đảm bảo rằng chúng đang truy cập thành viên dữ liệu đó trong khóa. Điều này trở nên đặc biệt có vấn đề khi những người khác (hoặc bạn) sửa đổi lớp học vào một ngày sau đó, họ phải nhớ để sử dụng khóa đó. Mặt khác, nếu lớp đó trở thành một diễn viên và thành viên dữ liệu trở thành một bộ đệm hoặc cổng bạn liên lạc với thông qua tin nhắn, bạn không phải nhớ lấy khóa vì ngữ nghĩa được tích hợp vào bộ đệm và bạn sẽ rất rõ ràng biết liệu bạn sẽ chặn nó dựa trên loại bộ đệm hay không.
-Rick
Việc sử dụng diễn viên là "tự nhiên" trong ít nhất hai trường hợp:
Ví dụ: nếu bạn xử lý dữ liệu phức tạp bằng một loạt bộ lọc, bạn sẽ dễ dàng sử dụng đường dẫn diễn viên nơi mỗi diễn viên nhận dữ liệu từ diễn viên thượng lưu và đặt dữ liệu cho diễn viên hạ lưu.
Tất nhiên luồng dữ liệu này không phải là tuyến tính và nếu một bước chậm trong đường ống, bạn có thể sử dụng thay vì một nhóm diễn viên làm cùng một công việc. Một cách khác để giải quyết các vấn đề cân bằng tải, sẽ là sử dụng thay vì một cách tiếp cận theo hướng nhu cầu được tổ chức với một loại hệ thống Kanban ảo.
Tất nhiên bạn sẽ cần đồng bộ hóa giữa các tác nhân trong hầu hết các trường hợp thú vị, nhưng trái với cách tiếp cận đa luồng cổ điển, đồng bộ hóa này thực sự là "cụ thể". Bạn có thể tưởng tượng những người trong một nhà máy, hãy tưởng tượng các vấn đề có thể xảy ra (công nhân hết công việc, hoạt động thượng nguồn quá nhanh và các sản phẩm trung gian cần một nơi lưu trữ lớn, vv) Bằng cách tương tự, bạn có thể tìm một giải pháp dễ dàng hơn.
Để thêm vào quan điểm của bạn, một trong những ưu điểm của lập trình hướng đối tượng là đóng gói dữ liệu và các chức năng liên quan. Tuy nhiên, người ta vẫn cần phải "cho cuộc sống" cho một đối tượng bằng cách gọi một trong những phương pháp của nó. Chúng tôi có một cái nhìn riêng biệt về các đối tượng và quy trình ở đó. Mặt khác, các diễn viên là các quy trình. Điều này giúp dễ dàng liên hệ chúng với thế giới thực. – tilish