Aktör modeli tanımım doğru mu?


13

Anladıysam, aktör modeli tıpkı nesne modeli gibidir, ancak birkaç farklılıkla:

  1. HER nesne kendi ayrı iş parçacığını ortaya çıkarır ve binlerce nesneniz olsa bile bu bir sorun değildir.
  2. Aktörler işlevleri çağırarak ve dönüş değerleri alarak etkileşimde bulunmazlar, bunun yerine mesaj gönderip alırlar.
  3. Bu modeli ihlal etmezseniz, uygulamanız yarış koşullarında herhangi bir risk olmadan tam gücüyle eşzamanlılık kullanacaktır.
  4. OO'da yapabileceğiniz her şeyi aktörler kullanarak yapabilirsiniz, ancak daha iyi, sorun, son yıllarda kodladığımız her şeyin OO tabanlı olmasıydı - ancak bir geçiş çok yakın.

Diyelim ki 3B vektör sınıfı / aktörü tanımlamam, iki örnek oluşturmam ve üzerlerinde bir toplama işlemi çağırmam gerekiyor.

NESNE ODAKLI:

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

AKTÖR MODELİ:

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
}

Öyle mi? Yoksa tamamen yanlış mıyım?


Hafif aktörler veya mikro ajanlar veya veri akışı bileşenleri mutlaka kendi iş parçacıklarını kullanmaz. :-) Şu terimleri kontrol edin: aktör tabanlı programlama, ajan tabanlı programlama, veri akışı tabanlı programlama. Çok benzerler, ancak farklı kısıtlamaları var. Ohh bunu bir soru olarak soracağım ;-)
inf3rno

Yanıtlar:


12

Kısa cevap hayır, doğru değil.

  1. makul derecede doğru başlar (her Aktör en azından potansiyel olarak bağımsız bir iş parçacığı olarak çalışır), ancak daha sonra büyük ölçüde raylardan çıkar. Modelde çok sayıda iş parçacığının iyi çalışmasını sağlayan hiçbir şey yoktur - bu uygulamaya bağlıdır. Çoğu zaman, çok sayıda iş parçacığı oluşturma kolaylığı, etkili iş parçacığı sağlamak için uygulamaya baskı uygular. En azından modelin umduğu kadarıyla, aktörler ve nesneler arasındaki benzerlik çoğunlukla rastlantısaldır. "Nesne", kod ve verileri nasıl birleştirdiğiniz konusunda oldukça belirgin etkiler taşır. Bir aktör genellikle hem kodu hem de verileri içerecektir, ancak bunların nasıl birleştirildikleri hakkında çok az şey ifade eder (dış dünya tarafından görülebilen tek verinin mesaj olması dışında).

  2. Etkileşimi tanımlamanın genel yolu mesaj gönderme gibidir, evet. Kullanışlı bir alıntım yok, ancak biri oldukça uzun zaman önce C ++ sanal fonksiyonları gibi mekanizmaların mesaj gönderme için izomorfik olduğunu kanıtladı (sanal fonksiyonlar normal olarak uygulandığından, bir vtable'a bir ofset kullanıyorsunuz - ancak bunun yerine ileti tablosuna bir uzaklık gönderdi, efekt aynı olurdu).

  3. Bu o kadar basit değil. Bir kopya bulabilirseniz, Henry Baker (adını şu an hatırlamadığım biriyle) Aktör modelinde veri tutarlılığı için gerekli kurallar hakkında bir makale yazdı.

  4. "Daha iyi" en iyi ihtimalle özneldir. Bazı problemler doğada oldukça paraleldir ve aslen asenkron olan asgari etkileşim ile gerçekten çok sayıda özerk varlığı içerir. Durum böyle olduğunda, aktör modeli gerçekten çok iyi çalışabilir. Diğer sorunlar için durum böyle değil. Bazı problemler neredeyse tamamen doğası gereği seri. Diğerleri paralel olarak yürütülebilir, ancak yine de bu eylemler arasında yakın senkronizasyon gerektirir (örneğin, her seferinde bir komut yürüttüğünüz, ancak her komut çok sayıda veri öğesine etki eder). Bu tür sorunların her ikisini de aktör modelini kullanarak çözmek kesinlikle mümkündür - ancak bu tür sorunlar için, karşılığında çok az kazanç elde etmek veya hiç kazanç elde etmemek için makul miktarda ekstra iş gerektirir.


Oyuncu sayısı ile iş parçacığı sayısı arasında bir ilişki yoktur; aktör modelinin garanti ettiği şey, belirli bir örneğin bir seferde yalnızca tek bir iş parçacığıyla çalıştırılacağıdır, bu nedenle aktörleriniz zaten iş parçacığı için güvenlidir ve içlerinde senkronizasyon ve kilitleme stratejileri kullanmanıza gerek yoktur.
Rob Crawford

@RobCrawford: Bu, Aktör modelinde veri tutarlılığını sağlamanın (oldukça önemsiz) bir yoludur. Hewitt / Baker gazetesi, ayrı iş parçacıklarında çalışan bir Aktörün birden fazla kopyası gibi daha fazla olasılığı kapsıyor (hmm ... cevabıma baktığımda, o zaman Carl Hewitt'in adını dürüstçe hatırlayamadığımı merak ediyorum ya da yazdığımda ironik olmak).
Jerry Coffin

Mesajın eşzamansızlığı modelin önemli bir unsurundan geçmiyor mu? Bu, doğada senkronize olan sanal işlev çağrılarıyla izomorfik olmasını kesinlikle engelleyecektir. Yoksa ayrım bazı açılardan ilgisiz mi?
17'de boycy

2

1 ile ilgili olarak: Tek (ish) dişli Aktör-modelli uygulama ile çalıştım, bu nedenle bunun önerdiği büyük iplik numarasını göz ardı etmek oldukça mümkündür. AFAIK, dişler hiçbir şekilde hafif nesneler değildir, bu nedenle kaç aktör kullandığınıza bağlı olarak muhtemelen her aktör için bir tane olması arzu edilmez.

3 ile ilgili: Eminim aktör modelli sistemlerde sadece programlama mantığı nedeniyle yarış koşullarının olabileceğinden eminim?

4 ile ilgili: 'Daha iyi' tanımlansın mı? Deneyimlerime göre, eşzamansız mantığın okunması eşzamanlı şeylerden çok daha zor olabilir. örneğin, yukarıdaki örnekte, hangi işlemin hangi sonuçtan sorumlu olduğunu bilmiyorsunuz, bu nedenle yapılacak ekstra mesaj izleme var. Bu eklendiğinde ve diğer iletiler içeri ve dışarı mantığa dahil edildiğinde, kodun amacı çeşitli gönderme / alma işlevlerine yayılır.

Tüm bunları söyledikten sonra, bir uygulamanın üst katmanları için büyük bir aktör modeli kullanımı hayranıyım. Bağımlılık eklemek bir işlev eklemekten biraz daha zor olduğu için ayırmayı kolaylaştırabilir. Ayrıca Java dillerinden daha yüksek bir seviyede deneyimim yok ve diğer paradigmalar asenkronizmi daha temel bir şekilde destekleyebilir.


# 1 ile ilgili: "thread" birçok şeyi ifade edebilir. İşletim sistemi iş parçacıkları genellikle oldukça ağır, doğrudur, ancak az sayıda işletim sistemi iş parçacığında yüzlerce, binlerce hatta milyonlarca yürütme "iş parçacığını" dahili olarak işleyen dil çalışma zamanları vardır. Bazı uygulamalarda, bu tür modeller görünüşte düzinelerce çekirdeğe kadar ölçekleniyor (Son GHC sürümlerinin 32 çekirdekli güzel oynadığına dair ifadeler gördüm).
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.