เหตุใดจึงเป็นความรับผิดชอบของผู้โทรเพื่อความปลอดภัยของเธรดในการเขียนโปรแกรม GUI?


37

ฉันเคยเห็นมาแล้วในหลาย ๆ ที่ว่ามันเป็นภูมิปัญญาที่ยอมรับ1ว่าเป็นความรับผิดชอบของผู้โทรเพื่อให้แน่ใจว่าคุณอยู่ในเธรด UI เมื่ออัปเดตองค์ประกอบ UI (โดยเฉพาะใน Java Swing ที่คุณอยู่ในEvent Dispatch Thread ) .

ทำไมเป็นเช่นนี้ Event Dispatch Thread เป็นปัญหาของมุมมองใน MVC / MVP / MVVM เพื่อจัดการที่ใดก็ได้ แต่มุมมองจะสร้างการเชื่อมต่ออย่างแน่นหนาระหว่างการนำไปใช้ของมุมมองและโมเดลการทำเกลียวของการปรับใช้มุมมองนั้น

โดยเฉพาะสมมติว่าฉันมีแอปพลิเคชันที่ออกแบบมาให้ใช้งาน MVC ซึ่งใช้ Swing ถ้าโทรเป็นผู้รับผิดชอบสำหรับส่วนประกอบปรับปรุงในกระทู้ที่จัดกิจกรรมส่งแล้วถ้าฉันพยายามที่จะสลับออกสวิงดูการดำเนินงานของฉันสำหรับการดำเนินงาน JavaFX ผมต้องเปลี่ยนทุกรหัส Presenter / ควบคุมการใช้ด้าย JavaFX ประยุกต์ใช้แทน

ดังนั้นฉันคิดว่าฉันมีสองคำถาม:

  1. เหตุใดจึงเป็นความรับผิดชอบของผู้โทรเพื่อให้มั่นใจในความปลอดภัยของเธรดส่วนประกอบ UI ข้อบกพร่องในการให้เหตุผลด้านบนของฉันอยู่ที่ไหน
  2. ฉันจะออกแบบแอปพลิเคชันของฉันให้มีเพศสัมพันธ์แบบหลวม ๆ เกี่ยวกับความปลอดภัยของเธรดเหล่านี้ได้อย่างไร แต่ยังคงปลอดภัยต่อเธรดอย่างเหมาะสม

ให้ฉันเพิ่มรหัส MCVE Java เพื่อแสดงให้เห็นถึงสิ่งที่ฉันหมายถึงโดย "ผู้เรียกที่รับผิดชอบ" (มีแนวทางปฏิบัติที่ดีอื่นที่นี่ที่ฉันไม่ได้ทำ แต่ฉันพยายามที่จะทำให้น้อยที่สุดเท่าที่จะทำได้):

ผู้โทรเป็นผู้รับผิดชอบ:

public class Presenter {
  private final View;

  void updateViewWithNewData(final Data data) {
    EventQueue.invokeLater(new Runnable() {
      public void run() {
        view.setData(data);
      }
    });
  }
}
public class View {
  void setData(Data data) {
    component.setText(data.getMessage());
  }
}

ดูความรับผิดชอบ:

public class Presenter {
  private final View;

  void updateViewWithNewData(final Data data) {
    view.setData(data);
  }
}
public class View {
  void setData(Data data) {
    EventQueue.invokeLater(new Runnable() {
      public void run() {
        component.setText(data.getMessage());
      }
    });
  }
}

1: ผู้เขียนของโพสต์นั้นมีคะแนนแท็กสูงสุดใน Swing on Stack Overflow เขาบอกว่าสิ่งนี้ทั่วทุกที่และฉันก็เห็นว่ามันเป็นความรับผิดชอบของผู้โทรในที่อื่น ๆ เช่นกัน


1
อ๊ะประสิทธิภาพ IMHO การโพสต์กิจกรรมเหล่านั้นไม่ได้มาฟรีและในแอปที่ไม่สำคัญคุณต้องการลดจำนวนของพวกเขา (และตรวจสอบให้แน่ใจว่าไม่มีใครมีขนาดใหญ่เกินไป) แต่การย่อ / กลั่นตัวนั้นควรทำอย่างมีเหตุผลในผู้นำเสนอ
58

1
@Ordous คุณยังสามารถมั่นใจได้ว่าการโพสต์มีน้อยในขณะที่วางแฮนด์ออฟเธรดในมุมมอง
durron597

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

1
SWT บังคับใช้แนวคิดเรื่องความปลอดภัยของเธรดโดยการโยนข้อยกเว้นถ้าคุณละเมิดมันไม่ใช่คนสวย แต่อย่างน้อยคุณก็ตระหนักถึงมัน คุณพูดถึงการเปลี่ยนจาก Swing เป็น JavaFX แต่คุณมีปัญหานี้กับเฟรมเวิร์ก UI ใด ๆ Swing ดูเหมือนว่าจะเป็นไฮไลต์ปัญหา คุณสามารถออกแบบเลเยอร์ระดับกลาง (ตัวควบคุมของตัวควบคุมได้หรือไม่) ซึ่งมีหน้าที่เพื่อให้แน่ใจว่าการซิงโครไนซ์การโทรไปยัง UI นั้นถูกต้อง เป็นไปไม่ได้ที่จะทราบได้อย่างแน่ชัดว่าคุณจะออกแบบส่วนที่ไม่ใช่ UI ของ API จากมุมมองของ API API ได้อย่างไร
MadProgrammer

1
และนักพัฒนาส่วนใหญ่จะบ่นว่าการป้องกันเธรดใด ๆ ที่นำไปใช้กับ UI API นั้นเป็นการ จำกัด หรือไม่ตรงกับความต้องการของพวกเขา ดีกว่าที่จะให้คุณตัดสินใจได้ว่าคุณต้องการแก้ปัญหานี้อย่างไรโดยขึ้นอยู่กับความต้องการของคุณ
MadProgrammer

คำตอบ:


22

ในตอนท้ายของการเขียนเรียงความในฝันของเขาที่ล้มเหลวเกรแฮมแฮมิลตัน (สถาปนิกชาว Java รายใหญ่) กล่าวถึงนักพัฒนาว่า "เพื่อรักษาความเท่าเทียมกับคิวเหตุการณ์แบบพวกเขาจะต้องปฏิบัติตามกฎที่ไม่ชัดเจน" โมเดลคิวเหตุการณ์ "ดูเหมือนว่าจะช่วยให้ผู้คนติดตามรูปแบบได้อย่างน่าเชื่อถือมากขึ้นและสร้างโปรแกรม GUI ที่ทำงานได้อย่างน่าเชื่อถือ"

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

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

โปรดทราบว่าปัญหาประเภทนี้เป็นชุดเครื่องมือของ GUI ทั้งหมด ทะนงรูปแบบการจัดส่งในกรณีที่พรีเซนเตอร์ของคุณ / ควบคุมไม่ได้มีเพศสัมพันธ์แน่นคุณเพียงคนเดียวโดยเฉพาะรูปแบบการเห็นพ้องด้วย GUI เครื่องมือของการมีเพศสัมพันธ์ก็ให้คุณทั้งหมดของพวกเขา อินเทอร์เฟซการจัดคิวเหตุการณ์ไม่น่าจะยากเกินคาด


25

เพราะการทำให้ GUI ด้ายปลอดภัยนั้นเป็นอาการปวดหัวและคอขวด

โฟลว์การควบคุมใน GUI มักจะไปใน 2 ทิศทางจากคิวเหตุการณ์ไปที่หน้าต่างรูตไปยังวิดเจ็ต gui และจากโค้ดแอปพลิเคชันไปยังวิดเจ็ตที่แพร่กระจายไปจนถึงหน้าต่างรูท

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

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


1
ที่น่าสนใจฉันแก้ปัญหานี้โดยมีกรอบการจัดคิวสำหรับการปรับปรุงเหล่านี้ที่ฉันเขียนที่จัดการเธรดแฮนด์ออฟ
durron597

2
@ durron597: และคุณไม่เคยอัปเดตใด ๆ ขึ้นอยู่กับสถานะปัจจุบันของ UI ที่อาจมีผลต่อเธรดอื่นหรือไม่ จากนั้นอาจใช้งานได้
Deduplicator

ทำไมคุณต้องล็อคที่ซ้อนกัน? ทำไมคุณต้องล็อคหน้าต่างรูททั้งหมดเมื่อทำงานกับรายละเอียดในหน้าต่างลูก คำสั่งล็อคเป็นปัญหาที่แก้ไขได้โดยจัดให้มีวิธีการสัมผัสเดียวเพื่อล็อคการล็อค mutliple ในลำดับที่ถูกต้อง (จากบนลงล่างหรือจากล่างขึ้นบน แต่ไม่ปล่อยให้ผู้โทรเข้า)
MSalters

1
@ MSters กับ root ฉันหมายถึงหน้าต่างปัจจุบัน ในการรับล็อคทั้งหมดที่คุณต้องได้รับคุณจำเป็นต้องเดินตามลำดับชั้นที่ต้องล็อคแต่ละคอนเทนเนอร์ในขณะที่คุณได้รับแม่และปลดล็อค (เพื่อให้แน่ใจว่าคุณล็อคจากบนลงล่างเท่านั้น) และหวังว่ามันจะไม่เปลี่ยนแปลง คุณหลังจากที่คุณได้หน้าต่างรูตและคุณล็อคจากบนลงล่าง
วงล้อประหลาด

@ratchetfreak: ถ้าเด็กที่คุณพยายามล็อคนั้นถูกเอาออกโดยเธรดอื่นในขณะที่คุณกำลังล็อคนั่นเป็นเพียงโชคร้ายเล็กน้อย แต่ไม่เกี่ยวข้องกับการล็อค คุณไม่สามารถทำงานกับวัตถุที่เพิ่งลบเธรดอื่นได้ แต่ทำไมเธรดอื่น ๆ จึงลบวัตถุ / windows ที่เธรดของคุณยังใช้อยู่อยู่ ไม่ดีในทุกสถานการณ์ไม่ใช่แค่ UI เท่านั้น
MSalters

17

Threadedness (ในรูปแบบหน่วยความจำที่ใช้ร่วมกัน) เป็นคุณสมบัติที่มีแนวโน้มที่จะท้าทายความพยายามที่เป็นนามธรรม ตัวอย่างง่ายๆคือSetชนิดในขณะที่Contains(..)และAdd(...)และUpdate(...)เป็น API AddOrUpdateที่ถูกต้องสมบูรณ์ในสถานการณ์เกลียวเดี่ยวสถานการณ์แบบมัลติเธรดต้องการ

เช่นเดียวกับ UI - หากคุณต้องการแสดงรายการที่มีจำนวนรายการอยู่ด้านบนของรายการคุณจะต้องอัปเดตทั้งสองอย่างในทุกการเปลี่ยนแปลง

  1. ชุดเครื่องมือไม่สามารถแก้ปัญหาดังกล่าวได้เนื่องจากการล็อกไม่ทำให้แน่ใจว่าลำดับการทำงานถูกต้อง
  2. มุมมองสามารถแก้ปัญหาได้ แต่ถ้าคุณอนุญาตกฎธุรกิจที่หมายเลขด้านบนของรายการจะต้องตรงกับจำนวนรายการในรายการและอัปเดตรายการผ่านมุมมองเท่านั้น ไม่ใช่สิ่งที่ MVC ควรจะเป็น
  3. ผู้นำเสนอสามารถแก้ไขได้ แต่จำเป็นต้องทราบว่ามุมมองมีความต้องการพิเศษเกี่ยวกับเธรด
  4. การเชื่อมต่อกับโมเดลที่มีความสามารถในการมัลติเธรดเป็นอีกทางเลือกหนึ่ง แต่นั่นทำให้รูปแบบซับซ้อนขึ้นด้วยสิ่งต่าง ๆ ที่น่ากังวลเกี่ยวกับ UI

ไม่มีของเหล่านั้นที่ดึงดูดจริงๆ การทำให้ผู้นำเสนอรับผิดชอบในการจัดการเธรดไม่แนะนำเพราะมันดี แต่เพราะมันใช้งานได้และทางเลือกนั้นแย่กว่า


อาจมีการนำเลเยอร์มาใช้ระหว่างมุมมองและผู้นำเสนอที่สามารถสลับเป็นชั้นได้
durron597

2
.NET มีการSystem.Windows.Threading.Dispatcherจัดการการแจกจ่ายทั้ง WPF และ WinForms UI-Threads เลเยอร์ชนิดนั้นระหว่างผู้นำเสนอและมุมมองนั้นมีประโยชน์อย่างแน่นอน แต่ให้ความเป็นอิสระของชุดเครื่องมือเท่านั้นไม่ใช่การทำเกลียวให้เป็นอิสระ
Patrick

9

ฉันอ่านบล็อกที่ดีจริง ๆ แล้วเมื่อไม่นานมานี้ซึ่งพูดถึงปัญหานี้ (กล่าวโดย Karl Bielefeldt) สิ่งที่พูดโดยทั่วไปคือมันอันตรายมากที่จะลองและทำให้เธรด UI kit ปลอดภัยเพราะแนะนำการหยุดชะงักที่เป็นไปได้ เงื่อนไขการแข่งขันในกรอบ

นอกจากนี้ยังมีการพิจารณาประสิทธิภาพ ไม่มากตอนนี้ แต่เมื่อสวิงเปิดตัวครั้งแรกมันถูกวิพากษ์วิจารณ์อย่างหนักสำหรับการทำงาน (ไม่ดี) แต่นั่นไม่ได้เป็นความผิดของ Swing จริงๆมันเป็นคนที่ขาดความรู้ด้วยวิธีการใช้งาน

SWT บังคับใช้แนวคิดเรื่องความปลอดภัยของเธรดโดยการโยนข้อยกเว้นถ้าคุณละเมิดมันไม่ใช่คนสวย แต่อย่างน้อยคุณก็ตระหนักถึงมัน

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

คุณพูดถึงการเปลี่ยนจาก Swing เป็น JavaFX แต่คุณจะมีปัญหานี้กับเฟรมเวิร์ก UI ใด ๆ (ไม่ใช่แค่ลูกค้าหนา แต่เป็นเว็บด้วย) Swing ดูเหมือนว่าจะเป็นไฮไลต์ที่เป็นปัญหา

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

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

โอเคคุณอาจแก้ปัญหานี้ได้โดยมีคิวบางอย่างที่สั่งเหตุการณ์ตามเวลาที่พวกเขาออก แต่นั่นไม่ใช่สิ่งที่เรามีอยู่แล้วใช่ไหม นอกจากนี้คุณยังไม่สามารถรับประกันได้ว่าเธรด B จะสร้างเหตุการณ์หลังจากเธรด A

เหตุผลหลักที่ผู้คนรู้สึกไม่สบายใจเกี่ยวกับการคิดเกี่ยวกับรหัสของพวกเขาเป็นเพราะพวกเขาคิดเกี่ยวกับรหัส / การออกแบบของพวกเขา "ทำไมมันไม่ง่ายกว่านี้?" มันไม่ง่ายกว่านี้เพราะมันไม่ใช่ปัญหาง่าย

ฉันจำได้ว่าตอนที่ PS3 วางจำหน่ายแล้วและ Sony กำลังพูดถึงตัวประมวลผลมือถือและมันมีความสามารถในการแยกสายของ logics ถอดรหัสเสียงวิดีโอโหลดและแก้ไขข้อมูลโมเดล ผู้พัฒนาเกมหนึ่งถามว่า "มันยอดเยี่ยมมาก แต่คุณจะซิงโครไนซ์กระแสได้อย่างไร"

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

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

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

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


2
คุณจะไม่มีปัญหากับเว็บนี้ JavaScript ไม่มีเจตนาสนับสนุนเธรด - JavaScript แบบรันไทม์เป็นเพียงคิวเหตุการณ์ใหญ่อย่างมีประสิทธิภาพ (ใช่ฉันรู้ว่าการพูดอย่างเคร่งครัด JS มี WebWorkers - สิ่งเหล่านี้เป็นเธรดที่ไม่ดีและทำตัวเหมือนนักแสดงในภาษาอื่น ๆ )
James_pic

1
@James_pic สิ่งที่คุณมีจริง ๆ แล้วคือส่วนหนึ่งของเบราว์เซอร์ที่ทำหน้าที่เป็นตัวประสานสำหรับคิวเหตุการณ์ซึ่งโดยทั่วไปแล้วสิ่งที่เราพูดถึงคือผู้ที่โทรเข้ามารับผิดชอบการตรวจสอบว่ามีการอัพเดทเกิดขึ้นกับคิวเหตุการณ์ชุดเครื่องมือ
MadProgrammer

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

1
ที่กล่าวว่ามีเฟรมเวิร์ก UI ของเบราว์เซอร์ที่มี event-loop-ภายใน -a-an-event-loop (ฉันกำลังดู Angular) เนื่องจากเฟรมเวิร์กเหล่านี้ไม่ได้รับการปกป้องโดยรันไทม์อีกต่อไปผู้เรียกต้องมั่นใจว่าโค้ดถูกเรียกใช้ภายในลูปเหตุการณ์คล้ายกับโค้ดมัลติเธรดในเฟรมเวิร์กอื่น
James_pic

จะมีปัญหาใด ๆ กับการมีตัวควบคุม "แบบแสดงผลอย่างเดียว" หรือไม่? หากมีการควบคุมข้อความที่แก้ไขได้ซึ่งเกิดขึ้นจากการเขียนโดยเธรดหนึ่งและการอ่านอื่น ๆ ไม่มีวิธีที่ดีที่จะทำให้การเขียนสามารถมองเห็นได้โดยไม่ต้องซิงโครไนซ์อย่างน้อยหนึ่งการกระทำเหล่านั้นกับสถานะ UI ของการควบคุม แต่ปัญหาใด ๆ ดังกล่าวจะมีผลต่อการควบคุมการแสดงผลเท่านั้น? ฉันคิดว่าสิ่งเหล่านั้นสามารถให้การล็อคหรืออินเตอร์ล็อกที่จำเป็นสำหรับการดำเนินการกับพวกเขาได้อย่างง่ายดายและอนุญาตให้ผู้โทรไม่สนใจเวลาที่ ...
supercat
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.