Cyflwyniad i Systemau Gweithredu
Hei Habr! Hoffwn dynnu eich sylw at gyfres o erthyglau-cyfieithiadau o un llenyddiaeth ddiddorol yn fy marn i - OSTEP. Mae'r deunydd hwn yn trafod yn eithaf dwfn waith systemau gweithredu tebyg i unix, sef, gwaith gyda phrosesau, amserlenwyr amrywiol, cof, a chydrannau tebyg eraill sy'n ffurfio OS modern. Gallwch weld y gwreiddiol o'r holl ddeunyddiau yma . Sylwch fod y cyfieithiad wedi'i wneud yn amhroffesiynol (yn eithaf rhydd), ond gobeithio i mi gadw'r ystyr cyffredinol.
Gellir dod o hyd i waith labordy ar y pwnc hwn yma:
Rhannau eraill:
Gallwch hefyd edrych ar fy sianel yn =)
Cynllunio: Ciw Adborth Aml-Lefel
Yn y ddarlith hon byddwn yn siarad am y problemau o ddatblygu un o'r dulliau enwocaf o
cynllunio, a elwir Ciw Adborth Aml-Lefel (MLFQ). Disgrifiwyd yr amserlennwr MLFQ gyntaf yn 1962 gan Fernando J. CorbatΓ³ mewn system o'r enw
System Rhannu Amser Gydnaws (CTSS). Y gweithiau hyn (gan gynnwys gweithiau diweddarach ar
Multics) wedi'u henwebu am Wobr Turing. Yr oedd y trefnydd
wedi hynny gwella a chaffael yr ymddangosiad y gellir ei ganfod eisoes yn
rhai systemau modern.
Mae'r algorithm MLFQ yn ceisio datrys 2 broblem sylfaenol sy'n gorgyffwrdd.
Yn gyntaf, mae'n ceisio gwneud y gorau o'r amser troi, sydd, fel y trafodwyd yn y ddarlith flaenorol, wedi'i optimeiddio gan y dull o ddechrau ar ddechrau'r ciw fwyaf
tasgau byr. Fodd bynnag, nid yw'r OS yn gwybod pa mor hir y bydd hyn neu'r broses honno'n rhedeg, a hyn
gwybodaeth angenrheidiol ar gyfer gweithredu algorithmau SJF, STCF. Yn ail, MLFQ yn ceisio
gwneud y system yn ymatebol i ddefnyddwyr (er enghraifft, ar gyfer y rhai sy'n eistedd a
gan syllu ar y sgrin wrth aros i'r dasg gael ei chwblhau) a thrwy hynny leihau'r amser
ymateb. Yn anffodus, mae algorithmau fel RR yn gwella amser ymateb, ond yn hynod
yn cael effaith wael ar y metrig amser gweithredu. Felly ein problem: Sut i ddylunio
trefnydd a fydd yn bodloni ein gofynion ac ar yr un pryd yn gwybod dim byd amdano
natur y broses, yn gyffredinol? Sut gall y trefnydd ddysgu nodweddion tasgau,
y mae'n ei lansio ac felly'n gwneud gwell penderfyniadau amserlennu?
Hanfod y broblem: Sut i gynllunio gosod tasgau heb wybodaeth berffaith?
Sut i ddylunio rhaglennydd sy'n lleihau'r amser ymateb ar yr un pryd
ar gyfer tasgau rhyngweithiol ac ar yr un pryd yn lleihau amser gweithredu heb yn wybod
gwybodaeth am amser cyflawni tasg?
Sylwch: dysgu o ddigwyddiadau blaenorol
Mae'r ciw MLFQ yn enghraifft wych o system sydd wedi'i hyfforddi arni
digwyddiadau yn y gorffennol i ragweld y dyfodol. Mae dulliau o'r fath yn aml
a geir yn yr OS (A llawer o ganghennau eraill mewn cyfrifiadureg, gan gynnwys canghennau
rhagfynegiadau caledwedd ac algorithmau caching). Codiadau tebyg
sbardun pan fydd gan dasgau gyfnodau ymddygiadol ac felly maent yn rhagweladwy.
Fodd bynnag, dylai un fod yn ofalus gyda'r dechneg hon, oherwydd mae rhagfynegiadau yn hawdd iawn.
gall droi allan i fod yn anghywir ac arwain y system i wneud penderfyniadau gwaeth
byddai heb wybodaeth o gwbl.
MLFQ: Rheolau Sylfaenol
Ystyriwch reolau sylfaenol yr algorithm MLFQ. Ac er bod y gweithrediadau yr algorithm hwn
mae yna sawl un, mae'r dulliau sylfaenol yn debyg.
Yn y gweithredu y byddwn yn ei ystyried, bydd gan MLFQ sawl un
ciwiau ar wahΓ’n, a bydd gan bob un ohonynt flaenoriaeth wahanol. Unrhyw bryd,
mae'r dasg sy'n barod i'w chyflawni yn yr un ciw. Mae MLFQ yn defnyddio blaenoriaethau,
i benderfynu pa dasg i'w rhedeg i'w chyflawni, h.y. dasg ag uwch
blaenoriaeth (tasg o'r ciw gyda'r flaenoriaeth uchaf) yn cael ei lansio ar y cyntaf
ciw.
Wrth gwrs, gall fod mwy nag un dasg mewn ciw penodol, felly
felly bydd ganddynt yr un flaenoriaeth. Yn yr achos hwn, bydd y mecanwaith yn cael ei ddefnyddio
RR i drefnu rhediad ymhlith y tasgau hyn.
Felly rydym yn cyrraedd dwy reol sylfaenol ar gyfer MLFQ:
- Rheol 1: Os blaenoriaeth (A) > Blaenoriaeth(B), bydd tasg A yn rhedeg (ni fydd B)
- Rheol 2: Os yw blaenoriaeth(A) = Blaenoriaeth(B), mae C&B yn cael ei ddechrau gan ddefnyddio RR
Yn seiliedig ar yr uchod, yr elfennau allweddol i gynllunio MLFQ
yn flaenoriaethau. Yn lle rhoi blaenoriaeth sefydlog i bob un
tasg, mae MLFQ yn newid ei flaenoriaeth yn dibynnu ar yr ymddygiad a arsylwyd.
Er enghraifft, os yw tasg yn rhoi'r gorau iddi yn gyson ar y CPU wrth aros am fewnbwn bysellfwrdd,
Bydd MLFQ yn cadw blaenoriaeth y broses yn uchel oherwydd dyna sut
dylai'r broses ryngweithiol weithio. Os, i'r gwrthwyneb, mae'r dasg yn gyson ac
yn defnyddio CPU yn drwm dros gyfnod hir, bydd MLFQ yn ei ostwng
yn flaenoriaeth. Felly, bydd MLFQ yn astudio ymddygiad prosesau ar yr adeg y maent yn rhedeg.
a defnyddio ymddygiadau.
Gadewch i ni dynnu enghraifft o sut y gallai'r ciwiau edrych ar ryw adeg
amser ac yna rydych chi'n cael rhywbeth fel hyn:
Yn y cynllun hwn, mae 2 broses A a B yn y ciw blaenoriaeth uchaf. Proses
Mae C rhywle yn y canol, ac mae proses D ar ddiwedd y ciw. Yn ol yr uchod
disgrifiadau o'r algorithm MLFQ, bydd y trefnydd ond yn cyflawni tasgau gyda'r uchaf
blaenoriaeth yn Γ΄l AP, a bydd tasgau C, D allan o waith.
Yn naturiol, ni fydd ciplun statig yn rhoi darlun cyflawn o sut mae MLFQ yn gweithio.
Mae'n bwysig deall yn union sut mae'r llun yn newid dros amser.
Ymgais 1: Sut i newid y flaenoriaeth
Ar y pwynt hwn, mae angen i chi benderfynu sut y bydd MLFQ yn newid y lefel flaenoriaeth
dasg (ac felly lleoliad y dasg yn y ciw) yn ystod ei chylch bywyd. Canys
o hyn, mae angen ichi gadw'r llif gwaith mewn cof: swm penodol
tasgau rhyngweithiol gydag amseroedd rhedeg byr (ac felly rhyddhau aml
CPU) a sawl tasg hir sy'n defnyddio'r CPU trwy gydol eu hamser gwaith, tra
nid yw amser ymateb ar gyfer tasgau o'r fath yn bwysig. Ac felly gallwch chi wneud yr ymgais gyntaf
gweithredu'r algorithm MLFQ gyda'r rheolau canlynol:
- Rheol 3: Pan fydd tasg yn mynd i mewn i'r system, caiff ei gosod yn y ciw gyda'r uchaf
- blaenoriaeth.
- Rheol 4a: Os yw tasg yn defnyddio ei ffenestr amser gyfan, yna mae'n
- mae'r flaenoriaeth yn cael ei gostwng.
- Rule4b: Os yw Tasg yn rhyddhau'r CPU cyn i'w ffenestr amser ddod i ben, yna fe
- yn parhau gyda'r un flaenoriaeth.
Enghraifft 1: Tasg hirfaith sengl
Fel y gwelwch yn yr enghraifft hon, mae'r dasg wrth dderbyn yn cael ei gosod gyda'r uchaf
blaenoriaeth. Ar Γ΄l ffenestr amser o 10ms, caiff y broses ei hisraddio mewn blaenoriaeth
trefnydd. Ar Γ΄l y ffenestr tro nesaf, mae'r dasg yn cael ei israddio i
flaenoriaeth isaf yn y system, lle mae'n parhau.
Enghraifft 2: Wedi codi tasg fer
Nawr, gadewch i ni weld enghraifft o sut y bydd MLFQ yn ceisio mynd at SJF. Yn hynny
enghraifft, dwy dasg: A, sy'n dasg hir-redeg yn gyson
meddiannu CPU a B, sy'n dasg ryngweithiol fer. Tybiwch
bod A eisoes wedi bod yn rhedeg ers peth amser erbyn i dasg B gyrraedd.
Mae'r graff hwn yn dangos canlyniadau'r senario. Tasg A, fel unrhyw dasg,
roedd defnyddio'r CPU ar y gwaelod. Bydd Tasg B yn cyrraedd amser T=100 a bydd
gosod yn y ciw blaenoriaeth uchaf. Gan fod yr amser rhedeg yn fyr,
bydd yn cwblhau cyn cyrraedd y ciw olaf.
O'r enghraifft hon, dylech ddeall prif nod yr algorithm: gan nad yw'r algorithm yn gwneud hynny
yn gwybod tasg hir neu un byr, yna yn gyntaf mae'n cymryd yn ganiataol bod y dasg
yn fyr ac yn rhoiβr flaenoriaeth uchaf iddo. Os yw hon yn dasg wirioneddol fyr, yna
bydd yn gweithredu'n gyflym, fel arall os yw'n dasg hir bydd yn symud yn araf
mewn blaenoriaeth i lawr a bydd yn profi yn fuan ei bod yn wir yn dasg hir nad yw'n
angen ymateb.
Enghraifft 3: Beth am I/O?
Nawr, gadewch i ni edrych ar enghraifft I / O. Fel y nodir yn rheol 4b,
os yw proses yn rhyddhau'r prosesydd heb ddefnyddio ei amser prosesydd yn llawn,
yna mae'n parhau ar yr un lefel flaenoriaeth. Mae bwriad y rheol hon yn eithaf syml.
- os yw'r swydd ryngweithiol yn cyflawni llawer o I/O, er enghraifft, aros amdano
o'r trawiadau bysell defnyddiwr neu'r llygoden, bydd tasg o'r fath yn rhyddhau'r prosesydd
cyn y ffenestr neilltuedig. Ni hoffem ostwng blaenoriaeth tasg o'r fath,
ac felly bydd yn aros ar yr un lefel.
Mae'r enghraifft hon yn dangos sut byddai'r algorithm yn gweithio gyda phrosesau o'r fath - tasg ryngweithiol B, sydd ond angen y CPU am 1ms cyn gweithredu
Proses I/O a swydd hir A, sy'n defnyddio'r CPU drwy'r amser.
Mae MLFQ yn cadw proses B ar y flaenoriaeth uchaf wrth iddo barhau
rhyddhau'r CPU. Os yw B yn dasg ryngweithiol, yna mae'r algorithm yn yr achos hwn wedi cyrraedd
Eich nod yw rhedeg tasgau rhyngweithiol yn gyflym.
Problemau gyda'r algorithm MLFQ cyfredol
Yn yr enghreifftiau blaenorol, rydym wedi adeiladu fersiwn sylfaenol o MLFQ. Ac y mae yn ymddangos ei fod ef
yn gwneud ei waith yn dda ac yn deg, gan ddosbarthu amser CPU yn deg rhwng
tasgau hir a chaniatΓ‘u tasgau byr neu dasgau y mae llawer o fynediad iddynt
i I/O i brosesu'n gyflym. Yn anffodus, mae'r dull hwn yn cynnwys sawl un
problemau difrifol.
Yn gyntaf, y broblem o newyn: os bydd y system yn cael llawer o rhyngweithiol
tasgau, byddant yn defnyddio'r holl amser CPU ac felly nid un hir
ni fydd y dasg yn cael cyfle i gael ei chyflawni (maen nhw'n newynu).
Yn ail, gallai defnyddwyr smart ysgrifennu eu rhaglenni fel bod
twyllo'r trefnydd. Mae'r twyll yn gorwedd mewn gwneud rhywbeth er mwyn gorfodi
trefnydd i roi mwy o amser CPU i'r broses. Mae'r algorithm sy'n
a ddisgrifir uchod yn eithaf agored i ymosodiadau o'r fath: cyn y ffenestr amser yn ymarferol
Wedi dod i ben, mae angen i chi berfformio gweithrediad I / O (i rai, ni waeth pa ffeil)
ac felly rhyddhau'r CPU. Bydd ymddygiad o'r fath yn caniatΓ‘u ichi aros yn yr un peth
y ciw ei hun ac eto yn cael canran fwy o amser CPU. Os gwneir
mae hyn yn gywir (e.e. rhedeg 99% o amser y ffenestr cyn rhyddhau'r CPU),
gall tasg o'r fath fonopoleiddio'r prosesydd.
Yn olaf, gall rhaglen newid ei hymddygiad dros amser. Y tasgau hynny
a ddefnyddiodd y CPU yn gallu dod yn rhyngweithiol. Yn ein hesiampl ni, cyffelyb
ni fydd tasgau'n cael eu trin yn briodol gan y trefnydd, fel y byddai eraill
tasgau rhyngweithiol (cychwynnol).
Cwestiwn i'r gynulleidfa: pa ymosodiadau ar yr amserlen y gellir eu gwneud yn y byd modern?
Ymgais 2: Cynyddu blaenoriaeth
Gadewch i ni geisio newid y rheolau a gweld a allwn osgoi problemau gyda
newyn. Beth allwn ni ei wneud i sicrhau bod cysylltiedig
Bydd tasgau CPU yn cael eu hamser (hyd yn oed os nad yn hir).
Fel ateb syml i'r broblem, gallwch awgrymu o bryd i'w gilydd
cynyddu blaenoriaeth pob tasg o'r fath yn y system. Mae yna lawer o ffyrdd
i gyflawni hyn, gadewch i ni geisio gweithredu rhywbeth syml fel enghraifft: cyfieithu
rhoddir y flaenoriaeth uchaf ar unwaith i bob tasg, a dyna pam y mae'r rheol newydd:
- Rheol5: Ar Γ΄l peth cyfnod S, trosglwyddwch yr holl dasgau yn y system i'r ciw uchaf.
Mae ein rheol newydd yn datrys dwy broblem ar unwaith. Yn gyntaf, y prosesau
yn sicr o beidio Γ’ newynu: bydd tasgau sydd yn y flaenoriaeth uchaf yn cael eu rhannu
Amser CPU yn Γ΄l yr algorithm RR ac felly bydd pob proses yn ei dderbyn
amser prosesydd. Yn ail, os yw rhai broses a ddefnyddiwyd yn flaenorol
dim ond y prosesydd sy'n dod yn rhyngweithiol, bydd yn aros yn y ciw gyda'r uchaf
flaenoriaeth ar Γ΄l derbyn hwb i'r flaenoriaeth uchaf unwaith.
Ystyriwch enghraifft. Yn y senario hwn, ystyriwch un broses gan ddefnyddio
CPU a dwy broses ryngweithiol, fer. Ar y chwith yn y ffigur, mae'r ffigur yn dangos yr ymddygiad heb hyrwyddo blaenoriaeth, ac felly mae'r dasg hirsefydlog yn dechrau llwgu ar Γ΄l i ddau dasg ryngweithiol gyrraedd y system. Yn y ffigwr ar y dde, mae cynnydd blaenoriaethol yn cael ei berfformio bob 50ms ac felly mae pob proses yn sicr o dderbyn amser CPU a bydd yn cael ei lansio o bryd i'w gilydd. Cymerir 50ms yn yr achos hwn fel enghraifft; mewn gwirionedd mae'r nifer hwn ychydig yn uwch.
Mae'n amlwg bod ychwanegu'r amser codi cyfnodol S yn arwain at
cwestiwn rhesymegol: pa werth y dylid ei osod? Un o'r rhai haeddiannol
galwodd y peirianwyr systemau John Ousterhout symiau o'r fath mewn systemau fel voo-doo
gyson, gan eu bod mewn rhyw ffordd angen hud du ar gyfer y cywir
cysylltiad. Ac, yn anffodus, mae gan S y fath flas. Os ydych chi'n gosod y gwerth hefyd
mawr - bydd tasgau hir yn dechrau llwgu. Ac os ydych chi'n gosod y gwerth yn rhy isel,
ni fydd tasgau rhyngweithiol yn cael amser CPU cywir.
Cais 3: Gwell Cyfrifo
Nawr mae gennym un broblem arall i'w datrys: sut i beidio
caniatΓ‘u i dwyllo ein trefnydd? Y tramgwyddwyr ar gyfer y posibilrwydd hwn yw
rheolau 4a, 4b sy'n caniatΓ‘u i swydd gadw ei blaenoriaeth trwy ryddhau'r prosesydd
cyn i'r amser penodedig ddod i ben. Sut i ddelio ag ef?
Gellir ystyried yr ateb yn yr achos hwn yn well cyfrifo amser CPU ar bob un
Lefel MLFQ. Yn lle anghofio'r amser a ddefnyddiwyd gan y rhaglen
prosesydd ar gyfer yr egwyl a neilltuwyd, dylech ei gymryd i ystyriaeth a'i gadw. Wedi
mae'r broses wedi defnyddio'r amser a neilltuwyd ganddi, dylid ei hisraddio i'r nesaf
lefel blaenoriaeth. Nawr nid oes ots sut y bydd y broses yn defnyddio ei amser - sut
cyfrifiadura yn gyson ar y prosesydd neu fel set o alwadau. Felly,
Dylid ailysgrifennu rheol 4 fel a ganlyn:
- Rheol4: Ar Γ΄l i dasg ddefnyddio'r amser a neilltuwyd ar ei gyfer yn y ciw presennol (waeth faint o weithiau y mae wedi rhyddhau'r CPU), mae blaenoriaeth tasg o'r fath yn cael ei leihau (mae'n symud i waelod y ciw).
Edrychwn ar enghraifft:
Β»
Mae'r ffigwr yn dangos beth sy'n digwydd os ydych chi'n ceisio twyllo'r trefnydd fel
pe bai gyda'r rheolau blaenorol 4a, 4b fyddai'r canlyniad ar y chwith. Gyda newydd
y rheol yw bod y canlyniad ar y dde. Cyn diogelu, gallai unrhyw broses ffonio I/O cyn ei chwblhau a
felly yn dominyddu'r CPU, ar Γ΄l galluogi amddiffyniad, waeth beth fo'u hymddygiad
I/O, bydd yn dal i fynd i lawr yn y ciw ac felly ni fydd yn gallu anonest
cymryd drosodd adnoddau CPU.
Gwella MLFQ a materion eraill
Gyda'r gwelliannau uchod, mae problemau newydd yn codi: un o'r prif
cwestiynau - sut i baramedroli trefnydd o'r fath? Y rhai. Faint ddylai fod
ciwiau? Beth ddylai maint ffenestr y rhaglen fod yn y ciw? Sut
yn aml dylid blaenoriaethu rhaglen er mwyn osgoi newyn a
i gymryd i ystyriaeth y newid yn ymddygiad y rhaglen? I'r cwestiynau hyn, nid oes unrhyw syml
ateb a dim ond arbrofion gyda llwythi a ffurfweddiad dilynol
gall trefnydd arwain at rywfaint o gydbwysedd boddhaol.
Er enghraifft, mae'r rhan fwyaf o weithrediadau MLFQ yn caniatΓ‘u ichi neilltuo gwahanol
slotiau amser ar gyfer gwahanol giwiau. Mae ciwiau blaenoriaeth uchel fel arfer
cyfnodau byr. Mae'r ciwiau hyn yn cynnwys tasgau rhyngweithiol,
newid rhwng sy'n eithaf sensitif a dylai gymryd 10 neu lai
Ms. Mewn cyferbyniad, mae ciwiau blaenoriaeth isel yn cynnwys tasgau hirsefydlog sy'n defnyddio
CPU. Ac yn yr achos hwn, mae cyfnodau hir yn cyd-fynd yn dda iawn (100ms).
Yn yr enghraifft hon mae 2 dasg a weithiodd mewn ciw blaenoriaeth uchel 20
ms, wedi'i rannu'n ffenestri 10ms. 40ms yn y ciw canol (ffenestr 20ms) ac yn y flaenoriaeth isel
Daeth ffenestr amser ciw yn 40ms lle cwblhaodd y tasgau eu gwaith.
Mae gweithredu MLFQ yn Solaris OS yn ddosbarth o amserlenwyr sy'n rhannu amser.
Bydd y trefnydd yn darparu set o dablau sy'n diffinio'n union sut y dylai
newid blaenoriaeth y broses dros gyfnod ei oes, beth ddylai fod y maint
ffenestr i'w dyrannu a pha mor aml i godi blaenoriaethau tasg. Gweinyddwr
Gall y system ryngweithio Γ’'r tabl hwn a gwneud i'r trefnydd ymddwyn
yn wahanol. Yn ddiofyn, mae gan y tabl hwn 60 ciw gyda chynnydd graddol
maint y ffenestr o 20ms (blaenoriaeth uchel) i rai cannoedd o ms (blaenoriaeth isaf), a
hefyd gyda hwb o bob tasg unwaith yr eiliad.
Nid yw trefnwyr MLFQ eraill yn defnyddio tabl nac unrhyw rai penodol
y rheolau a ddisgrifir yn y bennod hon, i'r gwrthwyneb, maent yn cyfrifo blaenoriaethau gan ddefnyddio
fformiwlΓ’u mathemategol. Er enghraifft, mae'r trefnydd yn FreeBSD yn defnyddio fformiwla ar gyfer
cyfrifo blaenoriaeth gyfredol tasg yn seiliedig ar ba mor hir yw'r broses
defnyddio'r CPU. Yn ogystal, mae defnydd CPU yn pydru dros amser, ac felly
Felly, mae blaenoriaeth gynyddol yn digwydd ychydig yn wahanol i'r hyn a ddisgrifir uchod. Mae hyn yn wir
a elwir yn algorithmau pydredd. O fersiwn 7.1, mae FreeBSD yn defnyddio'r amserlennydd ULE.
Yn olaf, mae gan lawer o amserlenwyr nodweddion eraill. Er enghraifft, rhai
mae amserlenwyr yn cadw lefelau uwch ar gyfer gweithrediad y system weithredu ac felly
Felly, ni all unrhyw broses defnyddiwr gael y flaenoriaeth uchaf i mewn
system. Mae rhai systemau yn eich galluogi i roi cyngor i helpu
y trefnydd i flaenoriaethu'n gywir. Er enghraifft, gan ddefnyddio'r gorchymyn braf
gallwch gynyddu neu leihau blaenoriaeth tasg a thrwy hynny gynyddu neu leihau
lleihau'r siawns y rhaglen ar gyfer amser CPU.
MLFQ: Crynodeb
Rydym wedi disgrifio dull cynllunio o'r enw MLFQ. Ei enw
wedi'i amgΓ‘u yn yr egwyddor o weithredu - mae ganddo sawl ciw ac mae'n defnyddio adborth
i flaenoriaethu tasg.
Bydd ffurf derfynol y rheolau fel a ganlyn:
- Rheol1: Os blaenoriaeth (A) > Blaenoriaeth(B), bydd tasg A yn cael ei lansio (ni fydd B)
- Rheol2: Os blaenoriaeth(A) = Blaenoriaeth(B), mae A&B yn cael eu cychwyn gan ddefnyddio RR
- Rheol3: Pan fydd tasg yn mynd i mewn i'r system, caiff ei gosod yn y ciw blaenoriaeth uchaf.
- Rheol4: Ar Γ΄l i dasg ddefnyddio'r amser a neilltuwyd ar ei gyfer yn y ciw presennol (waeth faint o weithiau y mae wedi rhyddhau'r CPU), mae blaenoriaeth tasg o'r fath yn cael ei leihau (mae'n symud i waelod y ciw).
- Rheol5: Ar Γ΄l peth cyfnod S, trosglwyddwch yr holl dasgau yn y system i'r ciw uchaf.
Mae MLFQ yn ddiddorol am y rheswm canlynol - yn lle bod angen gwybodaeth am
natur y dasg ymlaen llaw, mae'r algorithm yn dysgu ymddygiad gorffennol y dasg a setiau
blaenoriaethau yn unol Γ’ hynny. Felly, mae'n ceisio eistedd ar ddwy gadair ar unwaith - i gyflawni perfformiad ar gyfer tasgau bach (SJF, STCF) a rhedeg rhai hir yn onest,
Swyddi llwytho CPU. Felly, mae llawer o systemau, gan gynnwys BSD a'u deilliadau,
Mae Solaris, Windows, Mac yn defnyddio rhyw fath o algorithm fel y trefnydd
MLFQ fel llinell sylfaen.
Deunyddiau ychwanegol:
- (cyfrifiadura)
Ffynhonnell: hab.com