Linux operatsioonisüsteem kasutab lukku: erinevus redaktsioonide vahel
Allikas: Imre kasutab arvutit
Mine navigeerimisribaleMine otsikasti
Resümee puudub |
|||
| (ei näidata sama kasutaja 9 vahepealset redaktsiooni) | |||
| 14. rida: | 14. rida: | ||
* lukustamine lahendab moel või teisel ühiskasutuseks mõeldud ressursi kasutamise probleemi - nt lubab korraga kasutada ressurssi ühel actoril (mutex) või max näidatud arvul actoritel (semaphore) |
* lukustamine lahendab moel või teisel ühiskasutuseks mõeldud ressursi kasutamise probleemi - nt lubab korraga kasutada ressurssi ühel actoril (mutex) või max näidatud arvul actoritel (semaphore) |
||
| + | * kui maailmas olid ühe protsessoriga arvutid oli elu nö lihtsam - arvutil töötas üks kernel ja üks protsessor ja mälus oli üks komplekt nö struktuure |
||
| + | * kui maailma tekkisid mitme protsessoriga arvutid muutus elu keerulisemaks - arvutil töötas jätkuvalt üks kernel, aga nüüd konkureerisid mälu-struktuuride muutmisel mitu protsessorit ja midagi tuli ette võtta konfliktide ärahoidmiseks |
||
| + | * konfliktid olid vähem aktuaalsed user space'is ja kasu mitmest protsessorist oli kiiresti olemas user space'is - nt arvutusi nagu andmete järjestamised sai teha mitme protsessori peal samaaegselt kõrvuti |
||
| + | * konfliktid olid reljeefsemad kernel space'is ja kõige otsekohesem ja ebaefektiivsem oli neid ära hoida kasutades nn giant lock moodi lähenemist - st kui süsteemi mõni protsessor läks kernel space'i siis kõik muud protsessorid olid ootel enne kui said ka midagi teha kernel spece'is (user space'is said nad toimetada edasi) - st kernel space tegevusteks oli mitme protsessoriga arvuti efektiivselt ühe protsessoriga arvuti |
||
| + | * targa süsteemi programmeerimise tulemusena on 2026 aastaks suuresti olemas targemad lahendused - kernel space tegevusi saab ka teha paralleelselt mitme protsessori peal (nt võrguliiklusega tegeleda) |
||
| + | |||
| + | Nt OpenBSD puhul viimase ajani eemaldatakse kernel space juurest giant-lock lukustust |
||
| + | |||
| + | [[Fail:20260701-openbsd-giant-lock-01.png|1000px]] |
||
Misc |
Misc |
||
* mutex - mutul exclusive puhul üks execution proovib kasutada ühist ressurssi ja kui ei saab läheb nö magama |
* mutex - mutul exclusive puhul üks execution proovib kasutada ühist ressurssi ja kui ei saab läheb nö magama |
||
| − | * spinlock - istub cpu otsas ja ilma magamata ootab |
+ | * spinlock - istub cpu otsas ja ilma magamata ootab - tundub kallis, aga vahel lühike spin on otstarbekam ressursikasutuse seisukohalt kui lühike sleep |
* semaphore - nt |
* semaphore - nt |
||
* rwlock |
* rwlock |
||
* lock-free |
* lock-free |
||
| + | |||
| + | ===Tööpõhimõte - Python=== |
||
| + | |||
| + | Väited |
||
| + | |||
| + | * python virtual computer sees esinevad analoogselt nö tavalisele arvutile kaks nähtust - 1. kernel mode ja 2. user mode |
||
| + | * python virtaul computer sees nö käib mitte machine code, aga bytecode - 'python bytecode' |
||
| + | * python virtual computer user mode osakonnas toimuvad analoogselt arvutused, järjestused jms - see on ikka tulnud multi cpu väljakutsega toime |
||
| + | * python virtual computer kernel mode osakonnas toimub nt võrguliiklus ja andmesalvestus - nii nagu on see olnud väljakutse tavalisele operatsioonisüsteemile ja üldiselt on see ületatud (nn giant lock), python virtual machine 2026 aastal liigub selles suunas; on mõned frameworkid mis selle lahendavad |
||
| + | * üks meede lahendada python virtual machine sisest kernel mode multi cpu väljakutset on käivitada operatsioonisüsteemis mitmeid python virtual machine'isid |
||
| + | * mitmete machine'ide puhul on probleemiks suhteliselt suur mälukasutus - iga vajab suhteliselt palju compute ressurssi |
||
| + | * sellistel kaalutlustel võiks olla teatud iseloomuga workload (nt cpu intensiivne paralleelne nagu tavaliselt veebiserveri puhul) efektiivsem golang vms platvormidel |
||
| + | * java puhul esineb samuti virtual machine (jvm) kuid java jaoks on juba nö pikka aega jvm-sisene-kernel-mode-multi-cpu-challenge ära lahendatud |
||
===Kasulikud lisamaterjalid=== |
===Kasulikud lisamaterjalid=== |
||
Viimane redaktsioon: 2. juuli 2026, kell 19:05
Sissejuhatus
TODO
Mõisted
- Giant Lock
- Big Kernel Lock (BKL)
- mutex - mutual exclusive
Tööpõhimõte
Väited
- lukustamine lahendab moel või teisel ühiskasutuseks mõeldud ressursi kasutamise probleemi - nt lubab korraga kasutada ressurssi ühel actoril (mutex) või max näidatud arvul actoritel (semaphore)
- kui maailmas olid ühe protsessoriga arvutid oli elu nö lihtsam - arvutil töötas üks kernel ja üks protsessor ja mälus oli üks komplekt nö struktuure
- kui maailma tekkisid mitme protsessoriga arvutid muutus elu keerulisemaks - arvutil töötas jätkuvalt üks kernel, aga nüüd konkureerisid mälu-struktuuride muutmisel mitu protsessorit ja midagi tuli ette võtta konfliktide ärahoidmiseks
- konfliktid olid vähem aktuaalsed user space'is ja kasu mitmest protsessorist oli kiiresti olemas user space'is - nt arvutusi nagu andmete järjestamised sai teha mitme protsessori peal samaaegselt kõrvuti
- konfliktid olid reljeefsemad kernel space'is ja kõige otsekohesem ja ebaefektiivsem oli neid ära hoida kasutades nn giant lock moodi lähenemist - st kui süsteemi mõni protsessor läks kernel space'i siis kõik muud protsessorid olid ootel enne kui said ka midagi teha kernel spece'is (user space'is said nad toimetada edasi) - st kernel space tegevusteks oli mitme protsessoriga arvuti efektiivselt ühe protsessoriga arvuti
- targa süsteemi programmeerimise tulemusena on 2026 aastaks suuresti olemas targemad lahendused - kernel space tegevusi saab ka teha paralleelselt mitme protsessori peal (nt võrguliiklusega tegeleda)
Nt OpenBSD puhul viimase ajani eemaldatakse kernel space juurest giant-lock lukustust
Misc
- mutex - mutul exclusive puhul üks execution proovib kasutada ühist ressurssi ja kui ei saab läheb nö magama
- spinlock - istub cpu otsas ja ilma magamata ootab - tundub kallis, aga vahel lühike spin on otstarbekam ressursikasutuse seisukohalt kui lühike sleep
- semaphore - nt
- rwlock
- lock-free
Tööpõhimõte - Python
Väited
- python virtual computer sees esinevad analoogselt nö tavalisele arvutile kaks nähtust - 1. kernel mode ja 2. user mode
- python virtaul computer sees nö käib mitte machine code, aga bytecode - 'python bytecode'
- python virtual computer user mode osakonnas toimuvad analoogselt arvutused, järjestused jms - see on ikka tulnud multi cpu väljakutsega toime
- python virtual computer kernel mode osakonnas toimub nt võrguliiklus ja andmesalvestus - nii nagu on see olnud väljakutse tavalisele operatsioonisüsteemile ja üldiselt on see ületatud (nn giant lock), python virtual machine 2026 aastal liigub selles suunas; on mõned frameworkid mis selle lahendavad
- üks meede lahendada python virtual machine sisest kernel mode multi cpu väljakutset on käivitada operatsioonisüsteemis mitmeid python virtual machine'isid
- mitmete machine'ide puhul on probleemiks suhteliselt suur mälukasutus - iga vajab suhteliselt palju compute ressurssi
- sellistel kaalutlustel võiks olla teatud iseloomuga workload (nt cpu intensiivne paralleelne nagu tavaliselt veebiserveri puhul) efektiivsem golang vms platvormidel
- java puhul esineb samuti virtual machine (jvm) kuid java jaoks on juba nö pikka aega jvm-sisene-kernel-mode-multi-cpu-challenge ära lahendatud
