การกำหนดเวลาแบบมีส่วนร่วมหยุดกระบวนการชั่วคราวเมื่อดำเนินการ I / O

19

การอ้างอิงระบบปฏิบัติการหลายแห่งบอกว่าด้วยการทำงานหลายอย่างร่วมกัน (เมื่อเทียบกับการยึดเอาเสียก่อน) กระบวนการจะรักษา CPU จนกว่าจะระงับตัวเองโดยสมัครใจ หากกระบวนการที่กำลังดำเนินการตามคำขอ I / O ที่ไม่สามารถตอบสนองได้ทันที (เช่นขอให้ใช้รหัสจังหวะที่ยังไม่พร้อมใช้งาน) ตัวกำหนดตารางเวลาจะระงับหรือไม่เก็บ CPU ไว้จนกว่าจะสามารถให้บริการได้จริงหรือไม่

[แก้ไขเพื่อแทนที่ "บล็อกบน i / o" ด้วย "ทำการร้องขอ I / O ที่ไม่สามารถทำได้ทันที"]

operating-systems process-scheduling

— Ellen Spertus
แหล่งที่มา

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

— Raphael

3

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

— Ellen Spertus

15

ในการตั้งค่า "ความร่วมมือ" อย่างแท้จริงและหากไม่มีการป้องกันฮาร์ดแวร์กระบวนการสามารถบล็อก I / O และไม่ยกเลิกการควบคุมจนกว่า I / O จะเสร็จสิ้น (หรือไม่ละทิ้งการควบคุมเลย) ตัวอย่างเช่น Windows 3.1 เป็นวิธีนี้: หากกระบวนการผู้ใช้คนเดียวต้องการเข้ายึดคอมพิวเตอร์ทั้งหมดและป้องกันไม่ให้มีสิ่งอื่นใดทำงานก็อาจทำได้

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

— Carl Mummert
แหล่งที่มา

11

หากกระบวนการที่กำลังรันบล็อกบน i / o

การบล็อกบน IO นั้นเทียบเท่ากับการหยุดกระบวนการของคุณ ในบริบทของเคอร์เนล linux การเรียกใช้การเรียกระบบ IO บางอย่างเช่นread()จะทำให้ a sysenterหรือตัวจัดการอินเตอร์รัปต์ทริกเกอร์ให้ดูแล IO นั้นการเรียกdo_sys_read()ในท้ายที่สุด ที่นี่หากคำขอปัจจุบันไม่สามารถพึงพอใจได้ทันทีฟังก์ชันจะเรียกใช้sched()ซึ่งอาจดำเนินการกระบวนการอื่น

ในบริบทของระบบความร่วมมือฉันคาดหวังว่าเมื่อคุณทำการเรียกระบบด้วยเหตุผลบางอย่างของ IO หากคำขอไม่พอใจเคอร์เนลจะเลือกงานอื่นและดำเนินการนั้น เอกสารนี้ให้พื้นหลังบางส่วน - โดยทั่วไปถ้าคุณรอบน IO คุณอาจถูกแขวนตลอดไปเพื่อรอ IO นั้น แนวคิดของการจัดตารางเวลาแบบร่วมมือคือการที่คุณเรียกบ่อยครั้งsched()หรือเมธอด relinquish-the-cpu ที่เท่ากันถ้าทำภารกิจที่ใช้ CPU มาก

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

4

ในcooperative multitaskingโมเดลการจัดตารางเวลาแบบมีส่วนร่วม (ดีกว่า) ไม่มีแนวคิดของตัวกำหนดตารางเวลาในแง่ที่ว่าระบบปฏิบัติการไม่มีการควบคุมใด ๆ ว่ากระบวนการทำงานนานแค่ไหน

แอปพลิเคชันที่ตั้งโปรแกรมไว้อย่างถูกต้องจะยอมให้ CPU บน I / O โดยสมัครใจ แต่แอปพลิเคชันที่เขียนไม่ดีอาจรอ I / O ต่อเนื่องดังนั้นจึงปิดกั้นกระบวนการอื่น

PS: วิธีการนี้ได้รับการยอมแพ้ในภายหลังโดยส่วนใหญ่ของระบบปฏิบัติการในความโปรดปรานของการจัดตารางเวลาการยึดเอาเสียก่อน

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

— Ankit
แหล่งที่มา

2

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

— Gilles 'หยุดความชั่วร้าย'

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

— Ankit

4

การทำงานมัลติทาสก์แบบร่วมมือกันหมายความว่าบริบทการดำเนินการต้องยกเลิกการควบคุมไปยังตัวกำหนดตารางเวลาอย่างชัดเจนและหากต้องการสามารถป้องกันไม่ให้เกิดการสลับบริบทได้

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

โดยปกติจะเป็นไปได้สำหรับกระบวนการที่ล้มเหลว (หรือปฏิเสธการบริการที่เหลือของระบบโดยเจตนา) เพื่อป้องกันการสลับงานบ่อยครั้ง

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

— Pekka
แหล่งที่มา