คำอธิบายของฉันเกี่ยวกับนางแบบนักแสดงถูกต้องหรือไม่?


13

ถ้าฉันเข้าใจโมเดลนักแสดงก็เหมือนโมเดลวัตถุ แต่มีความแตกต่างเล็กน้อย:

  1. วัตถุทุกตัวมีเธรดแยกต่างหากและไม่มีปัญหาแม้ว่าคุณจะมีวัตถุนับพัน
  2. นักแสดงไม่ได้มีปฏิสัมพันธ์โดยการเรียกฟังก์ชั่นและรับค่าตอบแทน แต่เป็นการส่งและรับข้อความแทน
  3. หากคุณไม่ละเมิดรูปแบบดังกล่าวแอปของคุณจะใช้การทำงานพร้อมกันให้เต็มกำลังโดยไม่มีความเสี่ยงจากสภาพการแข่งขัน
  4. ทุกสิ่งที่คุณสามารถทำได้ใน OO คุณสามารถใช้นักแสดง แต่ดีกว่าปัญหาที่ว่าทุกอย่างที่เราเขียนในปีที่ผ่านมาเป็น OO แต่การเปลี่ยนแปลงนั้นใกล้เข้ามาแล้ว

ตัวอย่างเช่นสมมติว่าฉันต้องกำหนดคลาสเวกเตอร์ 3d / นักแสดงสร้างอินสแตนซ์ที่สองและเรียกใช้การดำเนินการรวมกับพวกเขา

วัตถุที่มุ่งเน้น:

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
}

มันคืออะไร หรือฉันผิดอย่างสมบูรณ์?


นักแสดงที่มีน้ำหนักเบาหรือ microagents หรือส่วนประกอบ dataflow ไม่จำเป็นต้องใช้เธรดของตัวเอง :-) ตรวจสอบเงื่อนไขต่อไปนี้: การเขียนโปรแกรมตามนักแสดง, การเขียนโปรแกรมโดยใช้ตัวแทน, การเขียนโปรแกรมตามดาต้าโฟลว์ พวกมันคล้ายกันมาก แต่มีข้อ จำกัด ต่างกัน โอ้ฉันจะถามสิ่งนี้เป็นคำถาม ;-)
inf3rno

คำตอบ:


12

คำตอบสั้น ๆ คือไม่มันไม่ถูกต้อง

  1. เริ่มต้นให้ถูกต้องอย่างสมเหตุสมผล (อย่างน้อยนักแสดงแต่ละคนอาจจะดำเนินการในฐานะที่เป็นกระทู้อิสระ) แต่จากนั้นส่วนใหญ่ก็ปิดทางรถไฟ ไม่มีอะไรเกี่ยวกับแบบจำลองที่ทำให้เธรดจำนวนมากทำงานได้ดี - ซึ่งขึ้นอยู่กับการนำไปใช้งาน อย่างมากความง่ายในการสร้างเธรดจำนวนมากสร้างแรงกดดันต่อการใช้งานเพื่อให้เธรดมีประสิทธิภาพ อย่างน้อยที่สุดเท่าที่นางแบบใส่ใจความคล้ายคลึงกันระหว่างนักแสดงและวัตถุต่าง ๆ ส่วนใหญ่เป็นเรื่องบังเอิญ "ออบเจ็กต์" มีความหมายเฉพาะอย่างชัดเจนเกี่ยวกับวิธีที่คุณรวมรหัสและข้อมูล โดยทั่วไปแล้วนักแสดงจะเกี่ยวข้องกับทั้งรหัสและข้อมูล แต่มีความหมายเพียงเล็กน้อยเกี่ยวกับวิธีการรวมตัวกันของพวกเขา (นอกเหนือจากข้อเท็จจริงที่ว่าข้อมูลที่มองเห็นได้จากโลกภายนอกนั้นเป็นเพียงข้อความ)

  2. วิธีปกติในการอธิบายการโต้ตอบนั้นเหมือนกับการส่งข้อความใช่ ฉันไม่ได้มีการอ้างอิงที่มีประโยชน์ แต่มีคนพิสูจน์มานานแล้วว่ากลไกเช่นฟังก์ชัน C ++ เสมือนนั้น isomorphic กับการส่งข้อความ ส่งออฟเซ็ตไปยังสารบัญแทนเอฟเฟกต์จะเหมือนกัน)

  3. มันไม่ง่ายอย่างนั้น หากคุณสามารถค้นหาสำเนาเฮนรี่เบเกอร์ (กับคนอื่นที่ฉันจำชื่อไม่ได้ในตอนนี้) เขียนบทความเกี่ยวกับกฎเกณฑ์ที่จำเป็นสำหรับความสอดคล้องของข้อมูลในแบบจำลองนักแสดง

  4. "ดีกว่า" เป็นอัตนัยที่ดีที่สุด ปัญหาบางอย่างขนานกันอย่างมากในธรรมชาติและเกี่ยวข้องกับหน่วยงานอิสระจำนวนมากโดยมีปฏิสัมพันธ์น้อยที่สุดซึ่งส่วนใหญ่ไม่ตรงกัน เมื่อเป็นเช่นนั้นแบบจำลองของนักแสดงสามารถทำงานได้ดีมากอย่างแน่นอน สำหรับปัญหาอื่น ๆ นั่นไม่ใช่เรื่องจริง ปัญหาบางอย่างเกือบทั้งหมดเป็นเรื่องปกติ คนอื่นสามารถดำเนินการในแบบคู่ขนาน แต่ยังคงต้องการการซิงโครไนซ์อย่างใกล้ชิดระหว่างการกระทำเหล่านั้น (เช่นโดยทั่วไปเป็นโหมดคล้าย SIMD ซึ่งคุณดำเนินการคำสั่งทีละครั้ง แต่แต่ละคำสั่งทำงานบนรายการข้อมูลจำนวนมาก) แน่นอนว่าเป็นไปได้ที่จะแก้ปัญหาทั้งสองประเภทนี้โดยใช้แบบจำลองของนักแสดง - แต่สำหรับปัญหาดังกล่าวมักจะเกี่ยวข้องกับงานพิเศษจำนวนมากเพื่อผลตอบแทนเพียงเล็กน้อยหรือไม่มีเลย


ไม่มีความสัมพันธ์ระหว่างจำนวนนักแสดงกับจำนวนกระทู้ สิ่งที่นักแสดงรุ่นการันตีคืออินสแตนซ์ที่กำหนดจะดำเนินการโดยเธรดครั้งเดียวเท่านั้นดังนั้นนักแสดงของคุณจึงปลอดภัยต่อเธรดแล้วและคุณไม่จำเป็นต้องใช้กลยุทธ์การซิงโครไนซ์และล็อคภายในพวกเขา
Rob Crawford

@ RobCrawford: เป็นวิธีหนึ่งที่ค่อนข้างมั่นใจในความสอดคล้องของข้อมูลในโมเดล Actor กระดาษ Hewitt / Baker ครอบคลุมความเป็นไปได้มากขึ้นเช่นสำเนานักแสดงหลายคนที่ทำงานในหัวข้อแยกกัน (อืมม ... ดูคำตอบของฉันฉันสงสัยว่าฉันไม่สามารถจำชื่อ Carl Hewitt ได้ในเวลานั้นหรือ จะแดกดันเมื่อฉันเขียนมัน)
Jerry Coffin

ไม่asynchronicityของข้อความผ่านองค์ประกอบสำคัญของรูปแบบ? ที่แน่นอนจะป้องกันไม่ให้ isomorphic ด้วยการเรียกใช้ฟังก์ชันเสมือนจริงซึ่งเป็นแบบซิงโครนัสในธรรมชาติ หรือความแตกต่างที่ไม่เกี่ยวข้องจากมุมมองบางอย่าง?
boycy

2

เกี่ยวกับ 1: ฉันได้ทำงานกับแอพพลิเคชั่นแบบจำลองเธรดเดียว (ish) ดังนั้นจึงค่อนข้างเป็นไปได้ที่จะไม่สนใจจำนวนเธรดขนาดใหญ่ที่แนะนำ AFAIK, เธรดไม่ได้เป็นวัตถุที่มีน้ำหนักเบาด้วยวิธีการใด ๆ ดังนั้นจึงอาจไม่เป็นที่ต้องการที่จะมีหนึ่งสำหรับนักแสดงแต่ละคนขึ้นอยู่กับจำนวนนักแสดงที่คุณใช้

เกี่ยวกับ 3: ฉันค่อนข้างมั่นใจว่าสภาพการแข่งขันสามารถเกิดขึ้นได้ในระบบแบบจำลองนักแสดงเนื่องจากตรรกะการเขียนโปรแกรม?

เกี่ยวกับ 4: กำหนด 'ดีกว่า'? ประสบการณ์ของฉันเป็นไปได้ว่าตรรกะแบบอะซิงโครนัสอาจอ่านได้ยากกว่าเรื่องแบบซิงโครนัส ตัวอย่างเช่นในตัวอย่างข้างต้นคุณไม่ทราบว่าการดำเนินการใดรับผิดชอบผลการค้นหาดังนั้นจึงมีการติดตามข้อความเพิ่มเติมที่ต้องทำ เมื่อมีการเพิ่มเข้าและข้อความอื่น ๆ เข้าและออกจะรวมอยู่ในตรรกะเจตนาของรหัสจะกระจายไปทั่วฟังก์ชั่นส่ง / รับหลาย

ต้องบอกว่าทั้งหมดนี้ฉันเป็นแฟนตัวยงของโมเดลนักแสดงใช้สำหรับเลเยอร์ด้านบนของแอปพลิเคชัน มันสามารถทำให้การถอดรหัสง่ายขึ้นเนื่องจากการเพิ่มการพึ่งพานั้นยากกว่าการเพิ่มฟังก์ชันเล็กน้อย ฉันยังไม่ได้มีประสบการณ์มากในระดับที่สูงกว่าภาษาจาวาและกระบวนทัศน์อื่น ๆ อาจสนับสนุนแบบอะซิงโครนัส - เนสส์ในลักษณะที่เป็นพื้นฐานมากกว่า


เกี่ยวกับ # 1: "ด้าย" สามารถอ้างถึงหลายสิ่งหลายอย่าง เธรดของระบบปฏิบัติการมักจะมีน้ำหนักค่อนข้างมาก, จริง แต่มีภาษาที่ใช้งานภายในซึ่งมีการจัดการ "เธรด" นับร้อยนับพันแม้กระทั่งการดำเนินการภายในเธรด OS จำนวนน้อย ในการติดตั้งใช้งานบางรุ่นนั้นเห็นได้ชัดว่าขยายได้ถึงหลายสิบคอร์ (ฉันเคยเห็นข้อความว่า GHC รุ่นล่าสุดเล่นได้ดีกับ 32 คอร์)
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.