Yanıtlar:
Aktör modeli mesaj geçişi üzerinde çalışır. Bireysel işlemlerin (aktörlerin) birbirlerine eşzamansız olarak mesaj göndermelerine izin verilir. Bunu normalde iş parçacığı modeli olarak düşündüğümüzden ayıran şey, (en azından teoride) paylaşılan bir durumun olmamasıdır. Ve eğer biri (haklı olarak, sanırım) paylaşılan devletin tüm kötülüklerin kökü olduğuna inanırsa, o zaman oyuncu modeli çok çekici hale gelir.
Yine de fazla heyecanlanmamalıyız. Oyuncu modeli (bazı iddiaların aksine) çıkmazların olmasını imkansız hale getirmiyor. Aktör modeli, farklı süreçler (örneğin mesaj kuyrukları) arasında kaynaklar için çekişme yaşamanızı da engellemez. Model, yalnızca belirli bir seviyenin üzerinde "kilitsizdir". Daha düşük bir seviyede, mesaj kuyruklarını koordine etmek için kilitleme hala gereklidir.
Bir konu bir oyuncu olarak görülüp diğer konulara mesaj gönderemez mi?
Hem evet hem hayır. Hayır, eğer muteksleri paylaşılan bellek konumlarının etrafına yerleştirme yaklaşımını kullanıyorsanız. Daha sonra iş parçacıkları bu durumu paylaşırlar - her ikisi de bu belleğe erişebilir, hem okuyabilir, yeniden yazabilir, vb. Ancak bir iş parçacığı modelinin üzerine bir aktör modeli oluşturabilirsiniz ve aslında tüm aktör uygulamalarının iş parçacıkları vardır altında. Her bir iş parçacığına muteks tarafından korunan bir sıra vererek buna benzer bir şeyi (çok kötü bir şekilde) hackledim - sadece eğlence için. Aktör-iş parçacığı empedansının nasıl yönetildiğine dair bir fikir edinmek için , bir yıl önceki soruma bakın .
Aktör Modelini farklı konuları kullanarak herhangi bir dilde kullanabilir miyim?
Evet, ama biraz daha çalışma gerektirecek. En sevdiğiniz dilin ileti aktaran bir kitaplığı olabilir, bu nedenle araştırmanız gereken ilk şey bu olur. Ayrıca, değişmez veri yapılarının kullanımını araştırmalısınız. Bir veri yapısı değişmez ise, o zaman esasen "paylaşılan durum" sorunuyla uğraştığınıza dikkat edin - birden çok iş parçacığı, kötü bir şey olmadan değişmez verilere referanslar tutabilir. Oyuncu dillerinin aynı zamanda işlevsel diller olma eğiliminde olmasının bir nedeni var (erlang, scala).
Farklı ama aynı zamanda zorlayıcı bir model olan Yazılım İşlem Belleğine de göz atmak isteyebilirsiniz. Clojure bunun en sevdiğim örneğidir.
Oyuncuların her zaman eşzamansız olarak mesaj ilettiğini söyleyemem - bu çok yavaş olur. JActor projesi, bir yöntem çağrısını daha iyi modellemek için 2 yönlü mesajlar (istek / yanıt) kullanır. Ve çoğu isteğe eşzamanlı olarak hizmet verilir.
JActor (bir Java kütüphanesi) ayrıca kilit kullanmaz. Yalnızca birkaç semaforun atıldığı bazı atomik ve eşzamanlı veri yapıları. İleti geçişi saniyede 0,8 Milyar mesajdır.