क्या अभिनेता मॉडल का मेरा वर्णन सही है?


13

अगर मुझे समझ में आया, अभिनेता मॉडल ऑब्जेक्ट मॉडल की तरह है, लेकिन कुछ अंतरों के साथ:

  1. हर एक वस्तु के अलग-अलग धागे होते हैं और जब आपके पास हजारों ऑब्जेक्ट होते हैं तब भी यह समस्या नहीं होती है।
  2. अभिनेता कॉल फ़ंक्शन और रिटर्न वैल्यू प्राप्त करने के बजाय बातचीत नहीं करते हैं, बल्कि संदेश भेजने और प्राप्त करने के द्वारा।
  3. यदि आप उस मॉडल का उल्लंघन नहीं करते हैं, तो आपका ऐप रेस की स्थिति के किसी भी जोखिम के बिना अपनी पूर्ण शक्ति के लिए संगामिति का उपयोग करेगा।
  4. सब कुछ आप ओओ में कर सकते हैं आप अभिनेताओं का उपयोग कर सकते हैं लेकिन बेहतर है, समस्या यह है कि पिछले वर्षों में हमने जो कुछ कोडित किया था वह ओओ आधारित था - लेकिन एक संक्रमण आसन्न है।

इसलिए, उदाहरण के लिए, मुझे लगता है कि मुझे 3 डी वेक्टर वर्ग / अभिनेता को परिभाषित करना है, दो उदाहरण बनाएं और उन पर एक राशि संचालन कॉल करें।

वस्तु के उन्मुख:

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

संकेतक मॉडल:

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
}

क्या यही है? या मैं पूरी तरह से गलत हूं?


हल्के अभिनेताओं या माइक्रोगेंट्स या डेटाफ्लो घटकों को जरूरी नहीं कि अपने स्वयं के धागे का उपयोग करें। :-) निम्नलिखित शब्दों की जाँच करें: अभिनेता-आधारित प्रोग्रामिंग, एजेंट-आधारित प्रोग्रामिंग, डेटाफ़्लो-आधारित प्रोग्रामिंग। वे बहुत समान हैं, लेकिन उनके पास अलग-अलग बाधाएं हैं। ओह, मैं इसे एक प्रश्न के रूप में
पूछूंगा

जवाबों:


12

संक्षिप्त उत्तर नहीं है, यह सही नहीं है।

  1. उचित रूप से सही शुरू होता है (प्रत्येक अभिनेता कम से कम संभावित रूप से एक स्वतंत्र धागे के रूप में निष्पादित करता है), लेकिन फिर बड़े पैमाने पर रेल बंद हो जाती है। उस मॉडल के बारे में कुछ भी नहीं है जो बहुत सारे धागे अच्छी तरह से काम करता है - जो कार्यान्वयन तक है। कम से कम, बहुत सारे धागे बनाने में आसानी कुशल थ्रेडिंग प्रदान करने के लिए कार्यान्वयन पर दबाव डालती है। कम से कम जहां तक ​​मॉडल की परवाह है, अभिनेताओं और वस्तुओं के बीच कोई समानता ज्यादातर संयोग है। "ऑब्जेक्ट" आप कोड और डेटा को कैसे संयोजित करते हैं, इसके बारे में काफी विशिष्ट निहितार्थ हैं। एक अभिनेता आम तौर पर कोड और डेटा दोनों को शामिल करता है, लेकिन इसका तात्पर्य है कि वे कैसे संयुक्त हैं (इस तथ्य के अलावा कि बाहरी दुनिया को दिखाई देने वाला एकमात्र डेटा संदेश है)।

  2. बातचीत का वर्णन करने का सामान्य तरीका संदेश भेजना है, हाँ। मेरे पास एक प्रशस्ति पत्र काम नहीं है, लेकिन किसी ने काफी समय पहले साबित कर दिया था कि सी + + वर्चुअल फ़ंक्शंस जैसे तंत्र संदेश भेजने के लिए आइसोमोर्फिक हैं (जैसा कि वर्चुअल फ़ंक्शंस आमतौर पर लागू होते हैं, आप एक ऑफसेट का उपयोग कर रहे हैं - लेकिन अगर आप इसके बजाय संदेशों की एक तालिका में एक ऑफसेट भेजा, प्रभाव समान होगा)।

  3. यह इतना आसान नहीं है। यदि आप एक प्रति प्राप्त कर सकते हैं, हेनरी बेकर (किसी और के साथ जिसका नाम मुझे अभी याद नहीं है) ने अभिनेता मॉडल में डेटा स्थिरता के लिए आवश्यक नियमों के बारे में एक पेपर लिखा था।

  4. "बेहतर" अत्यधिक व्यक्तिपरक है। कुछ समस्याएं प्रकृति में अत्यधिक समानांतर हैं, और वास्तव में बड़ी संख्या में अनिवार्य रूप से स्वायत्त संस्थाएं शामिल हैं, जिनमें न्यूनतम सहभागिता मुख्य रूप से अतुल्यकालिक है। जब ऐसा होता है, तो अभिनेता मॉडल वास्तव में बहुत अच्छी तरह से काम कर सकता है। अन्य समस्याओं के लिए, वास्तव में ऐसा नहीं है। कुछ समस्याएं प्रकृति में लगभग पूरी तरह से धारावाहिक हैं। दूसरों को समानांतर में निष्पादित किया जा सकता है, लेकिन फिर भी उन कार्यों के बीच घनिष्ठ समन्वय की आवश्यकता होती है (उदाहरण के लिए, अनिवार्य रूप से एक SIMD की तरह मोड, जहां आप एक समय में एक निर्देश निष्पादित करते हैं, लेकिन प्रत्येक निर्देश बड़ी संख्या में डेटा आइटम पर कार्य करता है)। अभिनेता मॉडल का उपयोग करके इन दोनों प्रकार की समस्याओं को हल करना निश्चित रूप से संभव है - लेकिन ऐसी समस्याओं के लिए, इसमें अक्सर कम या बिना बदले में कोई लाभ के लिए अतिरिक्त काम करना शामिल होता है।


अभिनेताओं की संख्या और धागों की संख्या के बीच कोई संबंध नहीं है; अभिनेता मॉडल क्या गारंटी देता है कि एक दिया गया उदाहरण केवल एक समय में एक ही थ्रेड द्वारा संचालित किया जाएगा, इसलिए आपके अभिनेता पहले से ही थ्रेड-सुरक्षित हैं और आपको उनके अंदर सिंक्रनाइज़ेशन और लॉकिंग रणनीतियों का उपयोग करने की आवश्यकता नहीं है।
रोब क्रॉफोर्ड

@ रोब्रॉफोर्ड: यह अभिनेता मॉडल में डेटा स्थिरता सुनिश्चित करने का एक (काफी तुच्छ) तरीका है। हेविट / बेकर पेपर अधिक संभावनाओं को शामिल करता है, जैसे कि अलग-अलग थ्रेड्स में चलने वाले एक अभिनेता की कई प्रतियां (हम्म ... मेरे उत्तर को देखते हुए, मैं सोच रहा हूं कि क्या मैं ईमानदारी से कार्ल हेविट का नाम उस समय याद नहीं कर सका, या था विडंबना होने के नाते जब मैंने इसे लिखा)।
जेरी कॉफिन

क्या संदेश का अतुल्यकालिकता मॉडल का एक अनिवार्य तत्व नहीं है? यह निश्चित रूप से आभासी फ़ंक्शन कॉल के साथ आइसोमॉर्फिक होने से रोक देगा, जो प्रकृति में तुल्यकालिक हैं। या भेद कुछ दृष्टिकोण से अप्रासंगिक है?
बॉयसी

2

1 के बारे में: मैंने सिंगल (ईश) थ्रेडेड एक्टर-मॉडलिंग एप्लिकेशन के साथ काम किया है, इसलिए यह सुझाव देता है कि बड़े थ्रेड नंबर की अवहेलना संभव है। AFAIK, थ्रेड्स किसी भी तरह से हल्के ऑब्जेक्ट नहीं हैं, इसलिए प्रत्येक अभिनेता के लिए एक होना संभव नहीं है, यह निर्भर करता है कि आप कितने अभिनेताओं का उपयोग कर रहे हैं।

3 के बारे में: मुझे यकीन है कि प्रोग्रामिंग लॉजिक के कारण अभिनेता की मॉडलिंग प्रणालियों में दौड़ की स्थिति हो सकती है?

4 के बारे में: 'बेहतर' परिभाषित करें? मेरा अनुभव रहा है कि एसिंक्रोनस लॉजिक को सिंक्रोनस सामान की तुलना में पढ़ना अधिक कठिन हो सकता है। उदाहरण के लिए, ऊपर दिए गए उदाहरण में, आप नहीं जानते कि कौन सा ऑपरेशन किस परिणाम के लिए जिम्मेदार है, इसलिए ऐसा करने के लिए अतिरिक्त संदेश ट्रैकिंग है। एक बार जब इन और आउट के अन्य संदेशों को तर्क में शामिल कर लिया जाता है, तो कोड का इरादा कई भेजे / प्राप्त कार्यों में फैल जाता है।

उस सब के बाद, मैं एक आवेदन की ऊपरी परतों के लिए अभिनेता मॉडल के उपयोग का एक बड़ा प्रशंसक हूं। यह डिकोडिंग को आसान बना सकता है, क्योंकि निर्भरता एक फ़ंक्शन को जोड़ने की तुलना में थोड़ी कठिन है। मुझे जावा भाषाओं की तुलना में उच्च स्तर के साथ बहुत अधिक अनुभव नहीं है, और अन्य प्रतिमान अधिक मौलिक तरीके से अतुल्यकालिक-नेस का समर्थन कर सकते हैं।


# 1 के बारे में: ठीक है, "धागा" कई चीजों को संदर्भित कर सकता है। ओएस थ्रेड्स आमतौर पर काफी भारी होते हैं, यह सच है, लेकिन भाषा के रनटाइम्स हैं जो आंतरिक रूप से सैकड़ों, हजारों, यहां तक ​​कि लाखों "थ्रेड्स" निष्पादित करते हैं जो ओएस थ्रेड्स की एक छोटी संख्या के भीतर संभालते हैं। कुछ कार्यान्वयनों में, इस तरह के मॉडल जाहिरा तौर पर दर्जनों कोर तक स्केल करते हैं (मैंने बयानों को देखा है कि हाल के जीएचसी संस्करण 32 कोर के साथ अच्छा खेलते हैं)।
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.