Linux operatsioonisüsteem kasutab lukku: erinevus redaktsioonide vahel

Viimane redaktsioon: 2. juuli 2026, kell 19:05

TODO

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

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

@@ 37. rida: / 37. rida: @@
 * 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