Tôi đọc một chương trong một cuốn sách (Seven languages in Seven Weeks của Bruce A. Tate) về Matz (Inventor of Ruby) nói rằng 'Tôi sẽ xóa chủ đề và thêm diễn viên, hoặc một số tính năng đồng thời cao cấp khác'.Mô hình diễn viên để thay thế mô hình luồng?
Nó không đến nỗi mô hình diễn viên sẽ thay thế chủ đề; ở cấp độ cpu, các quá trình sẽ vẫn có nhiều luồng được lên lịch và chạy trên lõi bộ xử lý. Ý tưởng của các diễn viên là thay thế sự phức tạp cơ bản này bằng một mô hình mà, những người ủng hộ của nó lập luận, làm cho các lập trình viên viết mã đáng tin cậy dễ dàng hơn.
Ý tưởng của diễn viên là phải có các luồng kiểm soát riêng biệt (các quy trình trong ngữ cảnh Erlang) giao tiếp độc quyền bằng cách truyền thông điệp. Một mô hình lập trình truyền thống hơn sẽ là chia sẻ bộ nhớ, và phối hợp truyền thông giữa các chủ đề bằng cách sử dụng mutexes. Điều này vẫn xảy ra dưới bề mặt trong mô hình diễn viên, nhưng các chi tiết được trừu tượng đi, và lập trình viên được đưa ra các nguyên thủy đáng tin cậy dựa trên thông điệp đi qua.
Một điểm quan trọng là các diễn viên không nhất thiết phải ánh xạ 1-1 đến chủ đề - trong trường hợp của Erlang, họ chắc chắn không - thường sẽ có nhiều quy trình Erlang trên mỗi luồng hạt nhân. Vì vậy, có phải là một lịch trình mà chỉ định diễn viên cho các chủ đề, và chi tiết này cũng trừu tượng ra khỏi lập trình ứng dụng.
Nếu bạn quan tâm đến mô hình diễn viên, bạn có thể muốn xem xét cách hoạt động trong Erlang hoặc Scala.
Nếu bạn quan tâm đến các loại nóng đồng thời mới, bạn có thể muốn xem software transactional memory, một cách tiếp cận khác có thể tìm thấy trong clojure và haskell.
Có thể nói rằng nhiều nỗ lực tích cực hơn trong việc tạo mô hình đồng thời nâng cao dường như đang diễn ra bằng các ngôn ngữ chức năng.Có thể là do niềm tin (tôi tự mình uống một số kool-aid này) sự bất biến đó làm cho sự tương tranh dễ dàng hơn nhiều.
tôi đã thực hiện câu hỏi này của tôi yêu thích và đang chờ đợi câu trả lời, nhưng vì vẫn còn không phải là, đây là của tôi ..
Tại sao và làm thế nào một người mẫu diễn viên có thể là một mô hình đồng thời tiên tiến rằng thay thế luồng?
Các diễn viên có thể loại bỏ trạng thái chia sẻ có thể thay đổi, rất khó để viết mã đúng. (Sự hiểu biết của tôi là) actors về cơ bản có thể được coi là đối tượng với các chủ đề riêng của chúng. Bạn gửi tin nhắn giữa các tác nhân sẽ được xếp hàng và tiêu thụ bởi chuỗi trong diễn viên. Vì vậy, bất kỳ trạng thái nào trong diễn viên được đóng gói và sẽ không được chia sẻ. Vì vậy, nó rất dễ dàng để mã ngay.
cũng thấy http://www.slideshare.net/jboner/state-youre-doing-it-wrong-javaone-2009
gì mô hình khác là những 'cao cấp mô hình đồng thời'?
thấy http://www.slideshare.net/jboner/state-youre-doing-it-wrong-javaone-2009
Xem Lập trình Dataflow. Đó là một cách tiếp cận, đó là một lớp trên đầu trang của thiết kế OOP bình thường. Bằng một số từ:
Các chương trình đang diễn ra 3 lớp:
Wikipedia là điểm khởi đầu tốt để hiểu được kinh doanh: http://en.wikipedia.org/wiki/Flow-based_programming Xem thêm "mô hình diễn viên", "dataflow lập trình" vv
Tôi không chắc chắn rằng tôi sẽ gọi Dataflow một lớp trên OOP, nhiều hơn một thay thế cho OOP với một số chéo khái niệm. Bạn có thể nói OOP theo Smalltalk là một ngôn ngữ hướng thông điệp, đó là những gì Dataflow nói về. –
Việc triển khai hệ thống dataflow yêu cầu OOP (hoặc ít nhất, đó là cách tự nhiên được khuyến nghị), tùy thuộc vào kiến trúc DF. Tôi đã viết một hệ thống DF, nơi mà dispatcher và các thành phần được viết bằng C++, các kết nối và tham số được định nghĩa bằng ngôn ngữ kịch bản lệnh, được biên dịch thành mã C++ và kết quả cuối cùng là a.out/ELF. Vì vậy, kiến trúc cơ bản là OOP, hệ thống DF được xây dựng trên đó. (Các lớp: Thông điệp, Cổng, Người tiêu dùng, Nhà sản xuất, Thành phần (trừu tượng), vv và tất nhiên là rất nhiều lớp thành phần). – ern0
hãy giấy sau
Cũng vui lòng xem
Lúc đầu, tôi nghĩ đây là một trò đùa, xem xét tất cả các nhãn hiệu trong tiêu đề. –
Tôi muốn đi xa hơn và nói rằng sự bất biến làm tăng độ mạnh của hệ thống. Tương tranh là một chiều kích của sự phức tạp của phần mềm, nơi sự khác biệt về độ mạnh là rất rõ ràng. Các hệ thống rất phức tạp có thể hưởng lợi từ việc sử dụng bất biến ngay cả khi không cần phải đáp ứng các vấn đề tương tranh. –
Ngoài ra, hãy nhớ rằng mô hình diễn viên cũng có thể được áp dụng trong một mạng, để phát triển một mô hình xử lý yêu cầu không đồng bộ. Trong thực tế, cho rằng đa lõi là có được các quy tắc, trừu tượng này thậm chí có thể thú vị trong một cấp api os (ít nhất nó là dành cho tôi). – Coyote21