ແນະນຳກ່ຽວກັບລະບົບປະຕິບັດການ

Hey Habr! ຂ້າພະເຈົ້າຢາກຈະເອົາມາໃຫ້ຄວາມສົນໃຈຂອງທ່ານຊຸດຂອງບົດຄວາມ - ການແປຂອງວັນນະຄະດີທີ່ຫນ້າສົນໃຈໃນຄວາມຄິດເຫັນຂອງຂ້າພະເຈົ້າ - OSTEP. ເອກະສານນີ້ສົນທະນາຢ່າງເລິກເຊິ່ງກ່ຽວກັບການເຮັດວຽກຂອງລະບົບປະຕິບັດການທີ່ຄ້າຍຄື unix, ຄື, ເຮັດວຽກກັບຂະບວນການ, ຕາຕະລາງຕ່າງໆ, ຫນ່ວຍຄວາມຈໍາ, ແລະອົງປະກອບທີ່ຄ້າຍຄືກັນອື່ນໆທີ່ປະກອບເປັນ OS ທີ່ທັນສະໄຫມ. ທ່ານສາມາດເບິ່ງຕົ້ນສະບັບຂອງວັດສະດຸທັງຫມົດທີ່ນີ້ ທີ່ນີ້. ກະລຸນາຮັບຊາບວ່າການແປແມ່ນເຮັດບໍ່ໄດ້ເປັນມືອາຊີບ (ຂ້ອນຂ້າງເສລີ), ແຕ່ຂ້ອຍຫວັງວ່າຂ້ອຍຈະຮັກສາຄວາມຫມາຍທົ່ວໄປ.

ວຽກງານຫ້ອງທົດລອງກ່ຽວກັບເລື່ອງນີ້ສາມາດພົບໄດ້ທີ່ນີ້:

• ຕົ້ນສະບັບ
• ຕົ້ນສະບັບ
• ການປັບຕົວສ່ວນຕົວຂອງຂ້ອຍ

ພາກສ່ວນອື່ນໆ:

• ສ່ວນທີ 1: ແນະນຳ
• ພາກທີ 2: Abstraction: ຂະບວນການ
• ສ່ວນທີ 3: ການແນະນໍາ API ຂະບວນການ
• ສ່ວນທີ 4: ການແນະນຳຕົວກໍານົດເວລາ

ທ່ານຍັງສາມາດກວດເບິ່ງຊ່ອງທາງຂອງຂ້ອຍໄດ້ທີ່ ໂທລະເລກ =)

ແນະນຳຕົວຈັດຕາຕະລາງ

ໂດຍເນື້ອແທ້ແລ້ວຂອງບັນຫາ: ວິທີການພັດທະນານະໂຍບາຍກໍານົດເວລາ
ກອບນະໂຍບາຍການກຳນົດເວລາພື້ນຖານຄວນຖືກອອກແບບແນວໃດ? ຄວນສົມມຸດຕິຖານທີ່ສໍາຄັນແນວໃດ? ຕົວຊີ້ວັດໃດທີ່ສໍາຄັນ? ເຕັກນິກພື້ນຖານອັນໃດທີ່ຖືກນໍາໃຊ້ໃນລະບົບຄອມພິວເຕີໃນຕອນຕົ້ນ?

ການສົມມຸດຕິຖານຂອງວຽກ

ກ່ອນທີ່ຈະປຶກສາຫາລືກ່ຽວກັບນະໂຍບາຍທີ່ເປັນໄປໄດ້, ທໍາອິດໃຫ້ພວກເຮົາເຮັດການຫຍໍ້ທໍ້ເລັກນ້ອຍກ່ຽວກັບຂະບວນການທີ່ເຮັດວຽກຢູ່ໃນລະບົບ, ເຊິ່ງເອີ້ນວ່າການລວບລວມ. ວຽກງານ. ການກໍານົດວຽກງານແມ່ນສ່ວນຫນຶ່ງທີ່ສໍາຄັນຂອງນະໂຍບາຍການກໍ່ສ້າງ, ແລະຫຼາຍທ່ານຮູ້ກ່ຽວກັບວຽກງານ, ນະໂຍບາຍທີ່ທ່ານສາມາດຂຽນໄດ້ດີກວ່າ.

ໃຫ້ສົມມຸດຕິຖານຕໍ່ໄປນີ້ກ່ຽວກັບຂະບວນການທີ່ເຮັດວຽກຢູ່ໃນລະບົບ, ບາງຄັ້ງກໍ່ເອີ້ນວ່າ ວຽກເຮັດງານທໍາ (ວຽກ). ເກືອບທັງຫມົດຂອງສົມມຸດຕິຖານເຫຼົ່ານີ້ບໍ່ແມ່ນຄວາມເປັນຈິງ, ແຕ່ມີຄວາມຈໍາເປັນສໍາລັບການພັດທະນາຄວາມຄິດ.

1. ວຽກ​ງານ​ແຕ່​ລະ​ແລ່ນ​ສໍາ​ລັບ​ຈໍາ​ນວນ​ທີ່​ໃຊ້​ເວ​ລາ​ດຽວ​ກັນ​,
2. ວຽກ​ງານ​ທັງ​ຫມົດ​ໄດ້​ຖືກ​ກໍາ​ນົດ​ພ້ອມ​ກັນ​,
3. ວຽກງານທີ່ໄດ້ຮັບມອບໝາຍໃຫ້ເຮັດວຽກຈົນສຳເລັດ,
4. ວຽກ​ງານ​ທັງ​ຫມົດ​ໃຊ້​ພຽງ​ແຕ່ CPU​,
5. ເວລາແລ່ນຂອງແຕ່ລະວຽກແມ່ນເປັນທີ່ຮູ້ຈັກ.

ຕົວວັດແທກຕາຕະລາງ

ນອກເຫນືອຈາກການສົມມຸດຕິຖານບາງຢ່າງກ່ຽວກັບການໂຫຼດ, ເຄື່ອງມືອື່ນສໍາລັບການປຽບທຽບນະໂຍບາຍການກໍານົດເວລາທີ່ແຕກຕ່າງກັນແມ່ນຈໍາເປັນ: metrics ຕາຕະລາງ. metric ແມ່ນພຽງແຕ່ມາດຕະການຂອງບາງສິ່ງບາງຢ່າງ. ມີຫຼາຍຕົວວັດແທກທີ່ສາມາດໃຊ້ເພື່ອປຽບທຽບຕາຕະລາງ.

ຕົວຢ່າງ, ພວກເຮົາຈະໃຊ້ metric ທີ່ເອີ້ນວ່າ ເວລາປ່ຽນ (ເວລາປ່ຽນ). ເວລາປ່ຽນວຽກແມ່ນຖືກກໍານົດເປັນຄວາມແຕກຕ່າງລະຫວ່າງເວລາສໍາເລັດວຽກແລະເວລາມາຮອດໃນລະບົບ.

Tturnaround=Tcompletion-Tarrival

ເນື່ອງຈາກວ່າພວກເຮົາສົມມຸດວ່າວຽກງານທັງຫມົດມາຮອດໃນເວລາດຽວກັນ, ຫຼັງຈາກນັ້ນ Ta = 0 ແລະດັ່ງນັ້ນ Tt = Tc. ມູນຄ່ານີ້ຈະປ່ຽນແປງຕາມທໍາມະຊາດເມື່ອພວກເຮົາປ່ຽນສົມມຸດຕິຖານຂ້າງເທິງ.

ຕົວ​ຊີ້​ວັດ​ອື່ນ - ຄວາມຍຸຕິທໍາ (ຄວາມຍຸດຕິທຳ, ຄວາມຊື່ສັດ). ຜົນຜະລິດແລະຄວາມຍຸດຕິທໍາມັກຈະເປັນລັກສະນະກົງກັນຂ້າມໃນການວາງແຜນ. ຕົວຢ່າງ, ຜູ້ກໍານົດເວລາອາດຈະເພີ່ມປະສິດທິພາບການປະຕິບັດ, ແຕ່ຄ່າໃຊ້ຈ່າຍໃນການລໍຖ້າວຽກງານອື່ນໆທີ່ຈະດໍາເນີນການ, ດັ່ງນັ້ນການຫຼຸດຜ່ອນຄວາມຍຸຕິທໍາ.

ຄັ້ງທໍາອິດໃນຄັ້ງທໍາອິດອອກ (FIFO)

ສູດການຄິດໄລ່ພື້ນຖານທີ່ສຸດທີ່ພວກເຮົາສາມາດປະຕິບັດໄດ້ຖືກເອີ້ນວ່າ FIFO ຫຼື ມາກ່ອນ, ຮັບໃຊ້ກ່ອນ (ອອກ). ສູດການຄິດໄລ່ນີ້ມີຄວາມໄດ້ປຽບຫຼາຍ: ມັນງ່າຍຫຼາຍທີ່ຈະປະຕິບັດແລະມັນເຫມາະສົມມຸດຕິຖານທັງຫມົດຂອງພວກເຮົາແລະເຮັດວຽກໄດ້ດີ.

ໃຫ້​ເຮົາ​ມາ​ເບິ່ງ​ຕົວຢ່າງ​ງ່າຍໆ. ສົມມຸດວ່າ 3 ວຽກຖືກຕັ້ງພ້ອມໆກັນ. ແຕ່ໃຫ້ສົມມຸດວ່າໜ້າວຽກ A ມາຮອດກ່ອນໜ້າວຽກທັງໝົດໜ້ອຍໜຶ່ງ, ສະນັ້ນ ມັນຈະປາກົດໃນລາຍການປະຕິບັດກ່ອນໜ້າວຽກອື່ນ, ຄືກັບ B ທຽບກັບ C. ໃຫ້ສົມມຸດວ່າແຕ່ລະອັນຈະຖືກປະຕິບັດເປັນເວລາ 10 ວິນາທີ. ເວລາສະເລ່ຍຈະເຮັດແນວໃດເພື່ອເຮັດສໍາເລັດວຽກງານເຫຼົ່ານີ້ໃນກໍລະນີນີ້?

ໂດຍການນັບຄ່າ - 10+20+30 ແລະຫານດ້ວຍ 3, ພວກເຮົາໄດ້ຮັບເວລາປະຕິບັດໂຄງການໂດຍສະເລ່ຍເທົ່າກັບ 20 ວິນາທີ.

ຕອນນີ້ໃຫ້ລອງປ່ຽນສົມມຸດຕິຖານຂອງພວກເຮົາ. ໂດຍສະເພາະ, ການສົມມຸດຕິຖານ 1 ແລະດັ່ງນັ້ນພວກເຮົາຈະບໍ່ສົມມຸດວ່າແຕ່ລະວຽກງານໃຊ້ເວລາດຽວກັນເພື່ອປະຕິບັດ. FIFO ຈະປະຕິບັດແນວໃດໃນເວລານີ້?

ຍ້ອນວ່າມັນຫັນອອກ, ເວລາປະຕິບັດວຽກງານທີ່ແຕກຕ່າງກັນມີຜົນກະທົບທາງລົບທີ່ສຸດຕໍ່ຜົນຜະລິດຂອງ FIFO algorithm. ໃຫ້ສົມມຸດວ່າໜ້າວຽກ A ຈະໃຊ້ເວລາ 100 ວິນາທີເພື່ອເຮັດສຳເລັດ, ໃນຂະນະທີ່ B ແລະ C ຍັງໃຊ້ເວລາ 10 ວິນາທີ.

ດັ່ງທີ່ເຫັນໄດ້ຈາກຮູບ, ເວລາສະເລ່ຍຂອງລະບົບຈະເປັນ (100+110+120)/3=110. ຜົນກະທົບນີ້ເອີ້ນວ່າ ຜົນກະທົບຂອງຂະບວນລົດ, ເມື່ອບາງຜູ້ບໍລິໂພກໃນໄລຍະສັ້ນຂອງຊັບພະຍາກອນຈະແຖວຫຼັງຈາກຜູ້ບໍລິໂພກຫນັກ. ມັນຄ້າຍຄືກັບເສັ້ນຢູ່ຮ້ານຂາຍເຄື່ອງໃນເວລາທີ່ມີລູກຄ້າຢູ່ທາງຫນ້າຂອງທ່ານດ້ວຍລົດເຂັນເຕັມ. ການແກ້ໄຂທີ່ດີທີ່ສຸດຂອງບັນຫາແມ່ນພະຍາຍາມປ່ຽນບັນຊີເງິນສົດຫຼືຜ່ອນຄາຍແລະຫາຍໃຈເລິກໆ.

ວຽກສັ້ນທີ່ສຸດກ່ອນ

ມັນເປັນໄປໄດ້ແນວໃດທີ່ຈະແກ້ໄຂສະຖານະການທີ່ຄ້າຍຄືກັນກັບຂະບວນການທີ່ມີນ້ໍາຫນັກ? ແນ່ນອນ. ປະເພດຂອງການວາງແຜນອື່ນເອີ້ນວ່າວຽກສັ້ນທີ່ສຸດກ່ອນ (SJF). ສູດການຄິດໄລ່ຂອງມັນແມ່ນຍັງຂ້ອນຂ້າງ primitive - ເປັນຊື່ຫມາຍຄວາມວ່າ, ວຽກງານທີ່ສັ້ນທີ່ສຸດຈະຖືກເປີດຕົວຄັ້ງທໍາອິດ, ຫນຶ່ງຫຼັງຈາກອື່ນ.

ໃນຕົວຢ່າງນີ້, ຜົນໄດ້ຮັບຂອງການດໍາເນີນການຂະບວນການດຽວກັນຈະເປັນການປັບປຸງເວລາການປ່ຽນໂຄງການໂດຍສະເລ່ຍແລະມັນຈະເທົ່າກັບ. 50 ແທນ 110, ເຊິ່ງເກືອບ 2 ເທົ່າ.

ດັ່ງນັ້ນ, ສໍາລັບການສົມມຸດຕິຖານທີ່ໃຫ້ວ່າວຽກງານທັງຫມົດມາຮອດໃນເວລາດຽວກັນ, SJF algorithm ເບິ່ງຄືວ່າເປັນສູດການຄິດໄລ່ທີ່ດີທີ່ສຸດ. ຢ່າງໃດກໍ່ຕາມ, ການສົມມຸດຕິຖານຂອງພວກເຮົາຍັງເບິ່ງຄືວ່າບໍ່ເປັນຈິງ. ເວລານີ້ພວກເຮົາປ່ຽນສົມມຸດຕິຖານ 2 ແລະເວລານີ້ຈິນຕະນາການວ່າວຽກງານສາມາດມີຢູ່ຕະຫຼອດເວລາ, ແລະບໍ່ແມ່ນທັງຫມົດໃນເວລາດຽວກັນ. ສິ່ງນີ້ສາມາດນໍາໄປສູ່ບັນຫາຫຍັງ?

ຂໍໃຫ້ຈິນຕະນາການວ່າວຽກງານ A (100c) ມາຮອດກ່ອນແລະເລີ່ມຕົ້ນທີ່ຈະປະຕິບັດ. ເມື່ອ t=10, ວຽກ B ແລະ C ມາຮອດ, ແຕ່ລະອັນຈະໃຊ້ເວລາ 10 ວິນາທີ. ດັ່ງນັ້ນເວລາປະຕິບັດໂດຍສະເລ່ຍແມ່ນ (100+(110-10)+(120-10))3 = 103. ຜູ້ຈັດຕາຕະລາງສາມາດເຮັດຫຍັງໄດ້ເພື່ອປັບປຸງສິ່ງນີ້?

ໄລຍະເວລາທີ່ສັ້ນທີ່ສຸດທີ່ຈະສໍາເລັດຄັ້ງທໍາອິດ (STCF)

ເພື່ອປັບປຸງສະຖານະການ, ພວກເຮົາຍົກເວັ້ນສົມມຸດຕິຖານ 3 ວ່າໂຄງການໄດ້ຖືກເປີດຕົວແລະດໍາເນີນການຈົນກ່ວາສໍາເລັດ. ນອກຈາກນັ້ນ, ພວກເຮົາຈະຕ້ອງການການສະຫນັບສະຫນູນຮາດແວແລະ, ຕາມທີ່ທ່ານອາດຈະຄາດເດົາ, ພວກເຮົາຈະໃຊ້ ເຄື່ອງຈັບເວລາ ເພື່ອຂັດຂວາງວຽກງານທີ່ເຮັດວຽກແລະ ສະ​ຫຼັບ​ສະ​ພາບ​ການ​. ດັ່ງນັ້ນ, ຜູ້ຈັດຕາຕະລາງສາມາດເຮັດບາງສິ່ງບາງຢ່າງເມື່ອວຽກງານ B, C ມາຮອດ - ຢຸດການປະຕິບັດວຽກງານ A ແລະເອົາວຽກງານ B ແລະ C ເຂົ້າໄປໃນການປຸງແຕ່ງ, ແລະຫຼັງຈາກສໍາເລັດຂອງພວກເຂົາສືບຕໍ່ປະຕິບັດຂະບວນການ A. ຕາຕະລາງດັ່ງກ່າວເອີ້ນວ່າ. STCFຫຼື ວຽກ​ທີ່​ມີ​ການ​ລ່ວງ​ລະ​ເມີດ​ຄັ້ງ​ທໍາ​ອິດ​.

ຜົນໄດ້ຮັບຂອງການວາງແຜນນີ້ຈະເປັນຜົນໄດ້ຮັບຕໍ່ໄປນີ້: ((120-0)+(20-10)+(30-10))/3=50. ດັ່ງນັ້ນ, ຕົວກໍານົດເວລາດັ່ງກ່າວກາຍເປັນສິ່ງທີ່ດີທີ່ສຸດສໍາລັບວຽກງານຂອງພວກເຮົາ.

ເວລາຕອບໂຕ້ Metric

ດັ່ງນັ້ນ, ຖ້າພວກເຮົາຮູ້ເວລາເຮັດວຽກຂອງວຽກງານແລະວ່າວຽກງານເຫຼົ່ານີ້ພຽງແຕ່ໃຊ້ CPU, STCF ຈະເປັນການແກ້ໄຂທີ່ດີທີ່ສຸດ. ແລະເມື່ອກ່ອນ, ສູດການຄິດໄລ່ເຫຼົ່ານີ້ເຮັດວຽກໄດ້ດີ. ຢ່າງໃດກໍ່ຕາມ, ຜູ້ໃຊ້ໃນປັດຈຸບັນໃຊ້ເວລາສ່ວນໃຫຍ່ຂອງນາງຢູ່ທີ່ສະຖານີແລະຄາດຫວັງວ່າປະສົບການການໂຕ້ຕອບທີ່ມີປະໂຫຍດ. ດັ່ງນັ້ນການວັດແທກໃຫມ່ໄດ້ເກີດມາ - ເວລາຕອບສະຫນອງ (ຄໍາຕອບ).

ເວລາຕອບສະຫນອງແມ່ນຄິດໄລ່ດັ່ງຕໍ່ໄປນີ້:

Tresponse=Tfistrun−Tarrival

ດັ່ງນັ້ນ, ສໍາລັບຕົວຢ່າງທີ່ຜ່ານມາ, ເວລາຕອບສະຫນອງຈະເປັນ: A=0, B=0, C=10 (abg=3,33).

ແລະມັນປາກົດວ່າ algorithm STCF ບໍ່ດີຫຼາຍໃນສະຖານະການທີ່ 3 ວຽກມາຮອດໃນເວລາດຽວກັນ - ມັນຈະຕ້ອງລໍຖ້າຈົນກ່ວາວຽກງານຂະຫນາດນ້ອຍຈະສໍາເລັດຢ່າງສົມບູນ. ດັ່ງນັ້ນ algorithm ແມ່ນດີສໍາລັບ metric ທີ່ໃຊ້ເວລາ turnaround, ແຕ່ບໍ່ດີສໍາລັບ metric ການໂຕ້ຕອບ. ລອງນຶກພາບເບິ່ງວ່າເຈົ້ານັ່ງຢູ່ບ່ອນໃດນຶ່ງ ພະຍາຍາມພິມຕົວອັກສອນໃສ່ຕົວແກ້ໄຂ ແລະຕ້ອງລໍຖ້າຫຼາຍກວ່າ 10 ວິນາທີ ເພາະບາງວຽກອື່ນກຳລັງເອົາ CPU ໄປ. ມັນບໍ່ເປັນສຸກຫຼາຍ.

ດັ່ງນັ້ນພວກເຮົາກໍາລັງປະເຊີນກັບບັນຫາອື່ນ - ພວກເຮົາສາມາດສ້າງຕົວກໍານົດເວລາທີ່ມີຄວາມອ່ອນໄຫວຕໍ່ກັບເວລາຕອບສະຫນອງແນວໃດ?

ຮອບໂຣນິນ

ສູດການຄິດໄລ່ໄດ້ຖືກພັດທະນາເພື່ອແກ້ໄຂບັນຫານີ້ ຮອບໂຣນິນ (RR). ແນວຄວາມຄິດພື້ນຖານແມ່ນຂ້ອນຂ້າງງ່າຍດາຍ: ແທນທີ່ຈະດໍາເນີນການວຽກງານຈົນກ່ວາພວກເຂົາສໍາເລັດ, ພວກເຮົາຈະດໍາເນີນການວຽກງານໃນໄລຍະເວລາທີ່ແນ່ນອນ (ເອີ້ນວ່າເວລາ slice) ແລະຫຼັງຈາກນັ້ນປ່ຽນໄປເຮັດວຽກອື່ນຈາກແຖວ. ສູດການຄິດໄລ່ຈະເຮັດຊໍ້າຄືນການເຮັດວຽກຂອງມັນຈົນກວ່າວຽກງານທັງໝົດຈະສຳເລັດ. ໃນ​ກໍ​ລະ​ນີ​ນີ້​, ເວ​ລາ​ແລ່ນ​ຂອງ​ໂຄງ​ການ​ຈະ​ຕ້ອງ​ເປັນ​ຫຼາຍ​ຂອງ​ເວ​ລາ​ທີ່​ຫຼັງ​ຈາກ​ນັ້ນ timer ຈະ​ຂັດ​ຂວາງ​ຂະ​ບວນ​ການ​. ຕົວຢ່າງ, ຖ້າເຄື່ອງຈັບເວລາຂັດຂວາງຂະບວນການທຸກໆ x = 10ms, ຫຼັງຈາກນັ້ນ, ຂະຫນາດຂອງຫນ້າຕ່າງການປະຕິບັດຂະບວນການຄວນຈະເປັນຄູນ 10 ແລະເປັນ 10,20 ຫຼື x * 10.

ຂໍໃຫ້ເບິ່ງຕົວຢ່າງ: ວຽກງານ ABC ມາຮອດພ້ອມໆກັນໃນລະບົບແລະພວກເຂົາແຕ່ລະຄົນຕ້ອງການດໍາເນີນການ 5 ວິນາທີ. ສູດການຄິດໄລ່ SJF ຈະເຮັດສຳເລັດແຕ່ລະໜ້າວຽກກ່ອນທີ່ຈະເລີ່ມອັນອື່ນ. ໃນທາງກົງກັນຂ້າມ, ສູດການຄິດໄລ່ RR ທີ່ມີປ່ອງຢ້ຽມເປີດຕົວ = 1s ຈະຜ່ານວຽກງານດັ່ງຕໍ່ໄປນີ້ (ຮູບ 4.3):

(SJF ອີກເທື່ອຫນຶ່ງ (ບໍ່ດີສໍາລັບເວລາຕອບສະຫນອງ)

(ຮອບ Robin (ດີສໍາລັບການຕອບໂຕ້)

ເວລາຕອບສະຫນອງສະເລ່ຍສໍາລັບ RR algorithm ແມ່ນ (0+1+2)/3=1, ໃນຂະນະທີ່ສໍາລັບ SJF (0+5+10)/3=5.

ມັນເປັນເຫດຜົນທີ່ຈະສົມມຸດວ່າປ່ອງຢ້ຽມເວລາເປັນຕົວກໍານົດການທີ່ສໍາຄັນສໍາລັບ RR; ຍິ່ງນ້ອຍກວ່າ, ເວລາຕອບສະຫນອງສູງ. ຢ່າງໃດກໍ່ຕາມ, ທ່ານບໍ່ຄວນເຮັດໃຫ້ມັນນ້ອຍເກີນໄປ, ເພາະວ່າເວລາປ່ຽນສະພາບການຈະມີບົດບາດໃນການປະຕິບັດໂດຍລວມ. ດັ່ງນັ້ນ, ທາງເລືອກຂອງເວລາປ່ອງຢ້ຽມການປະຕິບັດແມ່ນຖືກກໍານົດໂດຍສະຖາປະນິກ OS ແລະຂຶ້ນກັບວຽກງານທີ່ວາງແຜນທີ່ຈະປະຕິບັດໃນມັນ. ການສະຫຼັບສະພາບການບໍ່ແມ່ນການດໍາເນີນການບໍລິການດຽວທີ່ເສຍເວລາ - ໂປລແກລມແລ່ນດໍາເນີນການກັບສິ່ງອື່ນຫຼາຍ, ຕົວຢ່າງ, ແຄດຕ່າງໆ, ແລະແຕ່ລະສະວິດແມ່ນມີຄວາມຈໍາເປັນທີ່ຈະຊ່ວຍປະຢັດແລະຟື້ນຟູສະພາບແວດລ້ອມນີ້, ເຊິ່ງຍັງສາມາດໃຊ້ເວລາຫຼາຍ. ເວລາ.

RR ແມ່ນຕົວກໍານົດເວລາທີ່ດີຖ້າພວກເຮົາເວົ້າກ່ຽວກັບການວັດແທກເວລາຕອບສະຫນອງເທົ່ານັ້ນ. ແຕ່ການວັດແທກເວລາຂອງວຽກງານຈະປະຕິບັດຕົວແນວໃດກັບ algorithm ນີ້? ພິຈາລະນາຕົວຢ່າງຂ້າງເທິງ, ເມື່ອເວລາປະຕິບັດງານຂອງ A, B, C = 5s ແລະມາຮອດໃນເວລາດຽວກັນ. Task A ຈະສິ້ນສຸດຢູ່ທີ່ 13, B ຢູ່ 14, C ຢູ່ທີ່ 15s ແລະເວລາໝູນວຽນສະເລ່ຍຈະເປັນ 14ວິ. ດັ່ງນັ້ນ, RR ແມ່ນ algorithm ທີ່ຮ້າຍແຮງທີ່ສຸດສໍາລັບ metric ການປ່ຽນແປງ.

ໃນຄໍາສັບຕ່າງໆທົ່ວໄປ, algorithm ປະເພດ RR ໃດແມ່ນຍຸດຕິທໍາ; ມັນແບ່ງເວລາ CPU ເທົ່າທຽມກັນລະຫວ່າງຂະບວນການທັງຫມົດ. ແລະດັ່ງນັ້ນ, ຕົວຊີ້ວັດເຫຼົ່ານີ້ສະເຫມີຂັດແຍ້ງກັບກັນແລະກັນ.

ດັ່ງນັ້ນ, ພວກເຮົາມີ algorithms ກົງກັນຂ້າມຫຼາຍແລະໃນເວລາດຽວກັນຍັງມີຫຼາຍສົມມຸດຕິຖານທີ່ຍັງເຫຼືອ - ວ່າເວລາຂອງວຽກງານແມ່ນເປັນທີ່ຮູ້ຈັກແລະວ່າວຽກງານພຽງແຕ່ໃຊ້ CPU.

ປະສົມກັບ I/O

ກ່ອນອື່ນ ໝົດ, ໃຫ້ພວກເຮົາເອົາສົມມຸດຕິຖານ 4 ວ່າຂະບວນການພຽງແຕ່ໃຊ້ CPU; ຕາມທໍາມະຊາດ, ນີ້ບໍ່ແມ່ນກໍລະນີແລະຂະບວນການສາມາດເຂົ້າເຖິງອຸປະກອນອື່ນໆ.

ໃນຂະນະທີ່ຂະບວນການໃດຮ້ອງຂໍໃຫ້ມີການດໍາເນີນງານ I/O, ຂະບວນການເຂົ້າສູ່ສະຖານະທີ່ຖືກບລັອກ, ລໍຖ້າໃຫ້ I/O ສໍາເລັດ. ຖ້າ I/O ຖືກສົ່ງໄປຫາຮາດໄດ, ການດໍາເນີນງານດັ່ງກ່າວອາດຈະໃຊ້ເວລາເຖິງຫຼາຍ ms ຫຼືດົນກວ່ານັ້ນ, ແລະໂປເຊດເຊີຈະບໍ່ໄດ້ເຮັດວຽກໃນເວລານີ້. ໃນລະຫວ່າງເວລານີ້, ຕົວກໍານົດເວລາສາມາດຄອບຄອງໂຮງງານຜະລິດກັບຂະບວນການອື່ນໆ. ການຕັດສິນໃຈຕໍ່ໄປທີ່ຜູ້ກໍານົດເວລາຈະຕ້ອງເຮັດແມ່ນເວລາທີ່ຂະບວນການຈະສໍາເລັດ I/O ຂອງມັນ. ເມື່ອສິ່ງດັ່ງກ່າວເກີດຂື້ນ, ການຂັດຂວາງຈະເກີດຂື້ນແລະ OS ຈະເຮັດໃຫ້ຂະບວນການທີ່ເອີ້ນວ່າ I/O ເຂົ້າໄປໃນສະຖານະກຽມພ້ອມ.

ຂໍໃຫ້ເບິ່ງຕົວຢ່າງຂອງວຽກງານຈໍານວນຫນຶ່ງ. ແຕ່ລະອັນຕ້ອງການເວລາ CPU 50ms. ຢ່າງໃດກໍຕາມ, ອັນທໍາອິດຈະເຂົ້າເຖິງ I/O ທຸກໆ 10ms (ເຊິ່ງຈະຖືກປະຕິບັດທຸກໆ 10ms). ແລະຂະບວນການ B ພຽງແຕ່ໃຊ້ໂປເຊດເຊີ 50ms ໂດຍບໍ່ມີ I/O.

ໃນຕົວຢ່າງນີ້ພວກເຮົາຈະໃຊ້ຕົວກໍານົດເວລາ STCF. ຜູ້ກໍານົດເວລາຈະປະຕິບັດແນວໃດຖ້າຂະບວນການເຊັ່ນ A ຖືກເປີດຕົວໃນມັນ? ລາວຈະເຮັດດັ່ງຕໍ່ໄປນີ້: ທໍາອິດລາວຈະດໍາເນີນການຂະບວນການ A, ແລະຫຼັງຈາກນັ້ນຂະບວນການ B.

ວິທີການແບບດັ້ງເດີມເພື່ອແກ້ໄຂບັນຫານີ້ແມ່ນການປິ່ນປົວແຕ່ລະ 10 ms subtask ຂອງຂະບວນການ A ເປັນວຽກງານແຍກຕ່າງຫາກ. ດັ່ງນັ້ນ, ເມື່ອເລີ່ມຕົ້ນດ້ວຍ STJF algorithm, ການເລືອກລະຫວ່າງວຽກງານ 50 ms ແລະວຽກງານ 10 ms ແມ່ນຈະແຈ້ງ. ຫຼັງຈາກນັ້ນ, ເມື່ອວຽກຍ່ອຍ A ສໍາເລັດ, ຂະບວນການ B ແລະ I/O ຈະຖືກເປີດຕົວ. ຫຼັງຈາກ I/O ສໍາເລັດ, ມັນຈະເປັນປະເພນີທີ່ຈະເລີ່ມຕົ້ນຂະບວນການ 10ms A ອີກເທື່ອຫນຶ່ງແທນທີ່ຈະເປັນຂະບວນການ B. ດ້ວຍວິທີນີ້, ມັນເປັນໄປໄດ້ທີ່ຈະປະຕິບັດການຊ້ອນກັນ, ບ່ອນທີ່ CPU ຖືກນໍາໃຊ້ໂດຍຂະບວນການອື່ນໃນຂະນະທີ່ຂະບວນການທໍາອິດລໍຖ້າ. I/O. ແລະດັ່ງນັ້ນ, ລະບົບໄດ້ຖືກນໍາໄປໃຊ້ດີກວ່າ - ໃນປັດຈຸບັນໃນເວລາທີ່ຂະບວນການໂຕ້ຕອບກໍາລັງລໍຖ້າ I / O, ຂະບວນການອື່ນໆສາມາດຖືກປະຕິບັດຢູ່ໃນໂປເຊດເຊີ.

Oracle ແມ່ນບໍ່ມີອີກແລ້ວ

ໃນປັດຈຸບັນໃຫ້ເຮົາພະຍາຍາມກໍາຈັດການສົມມຸດຕິຖານວ່າເວລາແລ່ນຂອງວຽກງານແມ່ນເປັນທີ່ຮູ້ຈັກ. ໂດຍທົ່ວໄປແລ້ວນີ້ແມ່ນການສົມມຸດຕິຖານທີ່ຮ້າຍແຮງທີ່ສຸດແລະບໍ່ເປັນຈິງທີ່ສຸດໃນບັນຊີລາຍຊື່ທັງຫມົດ. ໃນຄວາມເປັນຈິງ, ໃນ OS ທໍາມະດາໂດຍສະເລ່ຍ, OS ຕົວຂອງມັນເອງມັກຈະຮູ້ຫນ້ອຍຫຼາຍກ່ຽວກັບເວລາປະຕິບັດວຽກງານ, ດັ່ງນັ້ນທ່ານສາມາດສ້າງຕາຕະລາງເວລາໂດຍບໍ່ຮູ້ວ່າວຽກງານຈະໃຊ້ເວລາດົນປານໃດ? ບາງທີພວກເຮົາສາມາດໃຊ້ຫຼັກການ RR ເພື່ອແກ້ໄຂບັນຫານີ້ບໍ?

ຜົນໄດ້ຮັບ

ພວກເຮົາໄດ້ເບິ່ງແນວຄວາມຄິດພື້ນຖານຂອງການຈັດຕາຕະລາງວຽກ ແລະເບິ່ງ 2 ຄອບຄົວຂອງຜູ້ຈັດຕາຕະລາງ. ອັນທໍາອິດເລີ່ມຕົ້ນວຽກງານທີ່ສັ້ນທີ່ສຸດກ່ອນແລະດັ່ງນັ້ນຈຶ່ງເພີ່ມເວລາການຫັນປ່ຽນ, ໃນຂະນະທີ່ອັນທີສອງແມ່ນ torn ລະຫວ່າງວຽກງານທັງຫມົດເທົ່າທຽມກັນ, ເພີ່ມເວລາຕອບສະຫນອງ. ທັງສອງ algorithms ແມ່ນບໍ່ດີທີ່ algorithms ຂອງຄອບຄົວອື່ນແມ່ນດີ. ພວກເຮົາຍັງໄດ້ເບິ່ງວ່າການໃຊ້ CPU ແລະ I/O ຂະຫນານສາມາດປັບປຸງປະສິດທິພາບໄດ້, ແຕ່ບໍ່ໄດ້ແກ້ໄຂບັນຫາກັບ OS clairvoyance. ແລະໃນບົດຮຽນຕໍ່ໄປພວກເຮົາຈະເບິ່ງຜູ້ວາງແຜນທີ່ເບິ່ງເຂົ້າໄປໃນອະດີດທັນທີທັນໃດແລະພະຍາຍາມຄາດຄະເນອະນາຄົດ. ແລະມັນຖືກເອີ້ນວ່າແຖວຄໍາຄຶດຄໍາເຫັນຫຼາຍລະດັບ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com