การวนรอบเหตุการณ์เป็นเพียงการวนรอบ / ขณะที่การหยั่งสัญญาณที่ปรับปรุงแล้ว

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

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

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

เหตุการณ์เป็นสิ่งที่เป็นนามธรรมที่ดีในการทำงานด้วย แต่เป็นเพียงสิ่งที่เป็นนามธรรม ฉันเชื่อว่าในท้ายที่สุดการเลือกตั้งไม่สามารถหลีกเลี่ยงได้ บางทีเราไม่ได้ทำมันในรหัสของเรา แต่ระดับที่ต่ำกว่า (การใช้ภาษาการเขียนโปรแกรมหรือระบบปฏิบัติการ) กำลังทำเพื่อเรา

โดยทั่วไปแล้วจะมากับรหัสเทียมต่อไปนี้ซึ่งทำงานอยู่ในระดับต่ำพอจึงไม่ทำให้เกิดการรอคอย:

while(True):
    do stuff
    check if event has happened (poll)
    do other stuff

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

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

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

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

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

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

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

while(True):
    do stuff
    check if event has happened (poll)
    do other stuff

ฉันคิดว่านี่เป็น:

on(some event):    //I got the baton
     do stuff
     signal the next level up    //Pass the baton

และระหว่างsignalและในครั้งถัดไปที่ตัวจัดการรันไม่มีแนวคิดที่จะรันโค้ดหรือวนลูป

ไม่มันไม่ใช่ "การทำโพลที่ดีที่สุด" ห่วงเหตุการณ์ใช้ I / O ที่ขับเคลื่อนด้วยอินเตอร์รัปต์แทนการสำรวจ

ในขณะที่จนถึงสำหรับ ฯลฯ ลูปเป็นลูปการเลือกตั้ง

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

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

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

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

เซมาฟอเรสสามารถเปลี่ยนแปลงได้ภายใต้การควบคุมซอฟต์แวร์และสามารถให้กลไกการส่งสัญญาณที่รวดเร็วและง่ายดายระหว่างกระบวนการซอฟต์แวร์

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

ฉันออกไปเยอะ แต่ต้องหยุดที่ไหนซักแห่ง โปรดถามว่าคุณต้องการรายละเอียดเพิ่มเติมหรือไม่

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

ฉันกำลังจะไปกับทุกคำตอบอื่น ๆ ฉันเห็นเพื่อให้ห่างไกลและพูดว่า"ใช่" ฉันคิดว่าคำตอบอื่น ๆ กำลังซับซ้อนเกินไป จากมุมมองแนวคิดของเหตุการณ์ลูปทั้งหมดเป็นหลัก:

while <the_program_is_running> {
    event=wait_for_next_event()
    process_event(event)
}

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

ทริกเกอร์เหตุการณ์ไม่ได้รับการจัดการทั้งหมดในลูป วิธีที่ฉันมักจะเขียนเอนจินเหตุการณ์ของตัวเองจะเป็นเช่นนี้:

interface Listener {
    void handle (EventInfo info);
}

List<Listener> registeredListeners

void triggerEvent (EventInfo info) {
    foreach (listener in registeredListeners) { // Memo 1
        listener.handle(info) // the handling may or may not be synchronous... your choice
    }
}

void somethingThatTriggersAnEvent () {
    blah
    blah
    blah
    triggerEvent(someGeneratedEventInfo)
    more blah
}

โปรดทราบว่าแม้ว่า Memo 1 จะอยู่ในลูป แต่การวนซ้ำนั้นใช้สำหรับการแจ้งผู้ฟังแต่ละคน ทริกเกอร์เหตุการณ์นั้นไม่จำเป็นต้องอยู่ในลูป

ในทางทฤษฎีเหตุการณ์สำคัญระดับ OS สามารถใช้เทคนิคเดียวกัน (แม้ว่าฉันคิดว่าพวกเขามักจะทำการสำรวจความคิดเห็นแทนฉันแค่คาดเดาที่นี่) หากระบบปฏิบัติการเปิดเผยregisterListenerAPI บางประเภท