Là mô tả của tôi về mô hình diễn viên phải không?

Nếu tôi hiểu, mô hình diễn viên giống như mô hình đối tượng, nhưng có một vài điểm khác biệt:

1. MỌI đối tượng sinh ra chủ đề riêng của nó và nó không phải là vấn đề ngay cả khi bạn có hàng ngàn đối tượng.
2. Các diễn viên không tương tác bằng cách gọi các chức năng và nhận các giá trị trả về mà thay vào đó bằng cách gửi và nhận tin nhắn.
3. Nếu bạn không vi phạm mô hình đó, ứng dụng của bạn sẽ sử dụng đồng thời với toàn bộ sức mạnh của nó mà không có bất kỳ rủi ro nào về điều kiện chủng tộc.
4. Mọi thứ bạn có thể làm trong OO bạn có thể làm bằng cách sử dụng các diễn viên nhưng tốt hơn, vấn đề là mọi thứ chúng ta mã hóa trong những năm qua đều dựa trên OO - nhưng một sự chuyển đổi sắp xảy ra.

Vì vậy, ví dụ, giả sử tôi phải xác định lớp / diễn viên vectơ 3d, tạo hai thể hiện và gọi một phép toán tổng trên chúng.

ĐỐI TƯỢNG ĐỊNH HƯỚNG:

class V3d {
   constructor V3d(x,y,z) //bla
   float x,y,z;
   function sum(V3d b) 
   { 
      return V3d(x+b.x,y+b.y,z+b.z); 
   }
}

//using:
mySum = V3d(1,2,3).sum(V3d(3,2,1)) //creates 2 instances, sum, returns instantly
drawPoint(mySum) //uses the result

MÔ HÌNH

actor V3d 
{
    constructor V3d(x,y,z) //bla
    float x,y,z;
    loop 
    {
       receive 'sum',b:V3d :
           send(caller,'sumResult',V3d(x+b.x,y+b.y,z+b.z))
    }
 }

//using:
send(V3d(1,2,3),'sum',V3d(3,2,1)) //creates 2 instances, send to the first one a request to sum with the second one

loop 
{
   receive 'sumResult',result:
      drawPoint(result) //receives result and draws it
}

Là nó? Hay tôi sai hoàn toàn?

Câu trả lời ngắn gọn là không, nó không đúng.

1. bắt đầu chính xác một cách hợp lý (mỗi diễn viên ít nhất có khả năng thực thi như một luồng độc lập), nhưng sau đó phần lớn đi ra khỏi đường ray. Không có gì về mô hình làm cho nhiều luồng hoạt động tốt - điều đó tùy thuộc vào việc thực hiện. Nhiều nhất, việc dễ dàng tạo ra nhiều luồng gây áp lực lên việc triển khai để cung cấp luồng hiệu quả. Ít nhất là theo như mô hình quan tâm, bất kỳ sự tương đồng giữa các diễn viên và các đối tượng chủ yếu là trùng hợp ngẫu nhiên. "Đối tượng" mang hàm ý khá cụ thể về cách bạn kết hợp mã và dữ liệu. Một diễn viên thường sẽ liên quan đến cả mã và dữ liệu, nhưng ngụ ý rất ít về cách họ kết hợp (ngoài thực tế là dữ liệu duy nhất hiển thị với thế giới bên ngoài là tin nhắn).

2. Cách thông thường để mô tả sự tương tác là gửi tin nhắn, vâng. Tôi không có tiện ích trích dẫn, nhưng ai đó đã chứng minh cách đây khá lâu rằng các cơ chế như các hàm ảo C ++ là dạng đồng nhất với việc gửi tin nhắn (vì các hàm ảo thường được triển khai, bạn đang sử dụng một offset vào vtable - nhưng nếu bạn thay vào đó đã gửi một phần bù vào một bảng thông báo, hiệu ứng sẽ như nhau).

3. Nó không hoàn toàn đơn giản. Nếu bạn có thể tìm thấy một bản sao, Henry Baker (với một người khác mà tôi không nhớ tên ngay bây giờ) đã viết một bài báo về các quy tắc cần thiết cho sự thống nhất dữ liệu trong mô hình Diễn viên.

4. "Tốt hơn" là chủ quan cao nhất ở tốt nhất. Một số vấn đề có tính chất song song cao và thực sự liên quan đến một số lượng lớn các thực thể tự trị cơ bản, với sự tương tác tối thiểu chủ yếu là không đồng bộ. Khi đó, mô hình diễn viên thực sự có thể làm việc rất tốt. Đối với các vấn đề khác, đó thực sự không phải là trường hợp. Một số vấn đề gần như hoàn toàn nối tiếp trong tự nhiên. Các hành động khác có thể được thực thi song song, nhưng vẫn yêu cầu đồng bộ hóa chặt chẽ giữa các hành động đó (ví dụ, về cơ bản là chế độ giống SIMD, trong đó bạn thực hiện một lệnh tại một thời điểm, nhưng mỗi lệnh hoạt động trên một số lượng lớn các mục dữ liệu). Chắc chắn có thể giải quyết cả hai loại vấn đề này bằng cách sử dụng mô hình diễn viên - nhưng đối với những vấn đề như vậy, nó thường liên quan đến một lượng công việc làm thêm khá ít hoặc không thu được lợi nhuận.

Về 1: Tôi đã làm việc với ứng dụng được mô hình hóa theo kiểu Actor đơn (ish), do đó hoàn toàn có thể bỏ qua số lượng luồng lớn mà điều này gợi ý. AFAIK, chủ đề không phải là vật thể nhẹ bằng bất kỳ phương tiện nào, vì vậy có lẽ không nên có một cái cho mỗi diễn viên, tùy thuộc vào số lượng diễn viên bạn đang sử dụng.

Về 3: Tôi khá chắc chắn điều kiện chủng tộc có thể xảy ra trong các hệ thống mô hình hóa diễn viên đơn giản là do logic lập trình?

Về 4: Xác định 'tốt hơn'? Kinh nghiệm của tôi là logic không đồng bộ có thể khó đọc hơn nhiều so với công cụ đồng bộ. ví dụ, trong ví dụ của bạn ở trên, bạn không biết thao tác nào chịu trách nhiệm cho kết quả nào, do đó cần phải theo dõi thêm thông báo. Khi được thêm vào và các thông báo khác vào và ra được đưa vào logic, mục đích của mã được trải rộng trên một số chức năng gửi / nhận.

Đã nói tất cả, tôi là một fan hâm mộ lớn của mô hình diễn viên sử dụng cho các lớp trên của một ứng dụng. Nó có thể làm cho việc tách rời dễ dàng hơn, vì việc thêm các phụ thuộc khó hơn một chút so với việc thêm một hàm. Tôi cũng không có nhiều kinh nghiệm với trình độ cao hơn các ngôn ngữ Java và các mô hình khác có thể hỗ trợ tính không đồng bộ theo cách cơ bản hơn.