Çfarë është bllokimi i kujtesës?

Historikisht, të gjitha programet kompjuterike janë shkruar në një mënyrë krejtësisht të njëpasnjëshme. Kjo është e thjeshtë për t'u lexuar, shkruar dhe kuptuar. Është gjithashtu e thjeshtë për një kompjuter për t'u ekzekutuar dhe kërkon një pajisje relativisht të thjeshtë. Me këtë paradigmë të projektimit, dy mënyrat e vetme për të rritur performancën e sistemit janë shkrimi i kodit më efikas dhe rritja e shpejtësisë së CPU-së. Rritja e efikasitetit të kodit mund të jetë e mundur, por në përgjithësi është një proces kompleks me rezultate shpesh të kufizuara.

Për dekada, performanca mund të ulet duke pritur për CPU të reja, më efikase. Siç përshkruhet nga ligji i Moore, CPU-të afërsisht dyfishohen në performancë çdo dy deri në tre vjet. Fatkeqësisht, shumica e këtyre përfitimeve të performancës erdhën nga përdorimi i nyjeve gjithnjë e më të vogla të prodhimit. Teknologjia moderne ka qenë duke luftuar për të ulur madhësinë e nyjeve me shpejtësinë historike, falë vështirësive materiale që punojnë në shkallën e nanometrave.

Për të kapërcyer këtë, arkitektët modernë të CPU-ve kanë zgjedhur të shtojnë bërthama të shumta procesori në CPU. Çdo bërthamë procesori mund të veprojë në mënyrë të pavarur në një detyrë të ndryshme. Ndërsa ata nuk mund të kombinojnë të njëjtin problem, ata mund të punojnë në dy çështje njëkohësisht. Ky ndryshim themelor arkitektonik ofron shumë performancë shtesë, por nuk përfiton drejtpërdrejt nga proceset individuale, megjithëse redukton grindjet për kohën e procesorit.

Për të përfituar nga CPU-të me shumë bërthama, kodi duhet të shkruhet në një mënyrë me shumë fije. Më pas, çdo thread mund të ekzekutohet njëkohësisht, duke shkallëzuar përfitimin e performancës me numrin e thread-ve dhe bërthamave të CPU-së në dispozicion. Megjithatë, bërja e kësaj përballet me një sfidë të re, "kushtin e garës".

Shënim: Disa detyra nuk mund të jenë me shumë fije, ndërsa të tjerat mund të jenë masivisht me shumë fije. Përfitimet e mundshme të performancës mbështeten në punën që po bëhet.

Kushtet e Garës

Softueri me shumë fije mund të përfitojë nga bërthama të shumta. Rreziqet përgjojnë në ato ujëra, gati për të zënë kurth programuesin e papërvojë. Një gjendje gare mund të ndodhë kur dy fije të ndryshme ndërveprojnë me të njëjtin pjesë të memories.

Një shembull i thjeshtë mund të jenë dy thread që përpiqen të kontrollojnë dhe rrisin një variabël në të njëjtën kohë. Le të themi se a=0 . Dy fije të ndryshme më pas kryejnë funksionet e tyre dhe, në një moment, kontrollojnë a dhe e rrisin atë me një. Në përgjithësi, do të prisni që rezultati i dy fijeve që shtojnë një në zero të jetë dy. Në shumicën e rasteve, ky duhet të jetë rasti. Ju mund të merrni një rezultat të ndryshëm nëse të dy fijet kalojnë në atë funksionalitet specifik saktësisht në kohën e duhur.

Në këtë rast, filli i parë lexon vlerën e një . Përpara se filli i parë të mund të rrisë vlerën e një megjithëse, filli i dytë e lexon atë. Tani filli i parë shton një në zero, por filli i dytë tashmë beson se vlera është zero, duke shtuar një në zero. Rezultati i kësaj është se vlera përfundimtare e a është 1, jo 2.

Gara drejt skenarit më të keq

Ndërsa shembulli i mësipërm mund të mos tingëllojë veçanërisht i keq, ai mund të ketë efekte dramatike. Po sikur vlera e a zgjedh mënyrën e funksionimit të një makine? Po sikur mënyrat specifike të funksionimit të asaj makinerie mund të jenë të rrezikshme apo edhe të rrezikshme për jetën?

Kushtet e garës gjithashtu nuk duhet të jenë aq të thjeshta. Për shembull, mund të jetë e mundur që një thread të lexojë një seksion memorie në të njëjtën kohë që një thread tjetër po shkruan në të. Në këtë rast, filli i leximit mund të marrë një përzierje të çuditshme të të dhënave nga para dhe pas. Le të themi se kontrolli është një kontroll i thjeshtë i vërtetë/false.

Nëse ndryshorja tha e vërtetë në fillim të leximit, por ishte në proces të mbishkrimit të fjalës false, rezultati i operacionit të leximit mund të jetë diçka si "trlse". Kjo nuk është "e vërtetë" apo "e rreme". Duke mos qenë asnjë nga dy opsionet në një zgjedhje binare, pothuajse me siguri do të rezultonte në rrëzimin e aplikacionit. Ky dëmtim i kujtesës mund të çojë në shumë çështje sigurie, të tilla si mohimi i shërbimit dhe përshkallëzimi i privilegjeve.

Mbyllja e Garës

Të dish se cilat pjesë të memories në një program ndahen midis temave të ndryshme është thelbësore për të parandaluar një gjendje gare. Asgjë nuk duhet bërë nëse një variabël kontrollohet dhe aksesohet vetëm nga një fill i vetëm. Nëse dy ose më shumë thread mund të hyjnë në një variabël, atëherë duhet të siguroheni që të gjitha operacionet në atë pjesë të memories të kryhen në mënyrë të pavarur nga njëri-tjetri.

Kjo pavarësi arrihet falë një bllokimi. Në kodin e një programi, duhet të vendosni një kyç kur shkruani një funksion që funksionon në një pjesë të përbashkët të memories. Ky kyç bllokon lidhjet e tjera nga aksesi në atë pjesë të memories derisa bllokimi të lirohet.

Kyçja nuk është zgjidhja më elegante. Për një gjë, ajo ka shpenzime të përgjithshme të memories. Ai gjithashtu mund të detyrojë një fije të varet, duke pritur që një bllokues të lëshohet. Në varësi të situatës, bllokimi mund të mos lirohet për një kohë shumë të gjatë ose mund të mos lirohet fare. Në një skenar të rastit më të keq, zhbllokimi i një bllokimi mund të varet nga diçka që ndodh në një fije tjetër të bllokuar, duke çuar në një bllokim.

Është thelbësore të optimizoni përdorimin e bravave. Ju mund të kontrolloni se sa grimcuar është bllokimi. Për shembull, nëse jeni duke redaktuar të dhëna në një tabelë, mund të kyçni të gjithë tabelën ose të kyçni vetëm rreshtin e redaktuar. Bllokimi i të gjithë tryezës do të ishte një bllokim i trashë. Ai minimizon shpenzimet e sipërme nga zbatimi i shumë bravave, por rrit mundësinë që një fije tjetër të bllokohet nga kyçi. Bllokimi i vetëm rreshtit do të ishte një bllokim i hollësishëm. Kjo ka shumë më pak gjasa të ndërhyjë me fijet e tjera, por do të thotë se do të nevojiten bllokime të grisura, duke rritur koston totale.

konkluzioni

Kyçja e memories është një mjet kodi që përdoret për të siguruar funksionimin e atomicitetit në memorie në një mjedis me shumë fije. Duke kyçur një pjesë të kujtesës përpara se ta përdorni, mund të jeni i sigurt se nuk mund të ndodhë asnjë sjellje e papritur për shkak të një gjendje gare. Blloqet e memories vijnë me një memorie të lartë, por gjithashtu mund të shkaktojnë bllokim.

Bllokimi është vendi ku një fije tjetër përpiqet të operojë në një pemory të bllokuar. Fije qëndron atje, e bllokuar derisa të lirohet bllokimi. Kjo mund të shkaktojë probleme nëse lëshimi i bllokimit kërkon një fije tjetër për të bërë diçka, pasi mund të bllokohet përpara se të mund të plotësojë parakushtet për të liruar bllokimin që e bllokon. Blloqet e memories mund të shmangen duke shkruar kode jo-bllokuese. Të bësh këtë, megjithatë, mund të jetë komplekse dhe më pak efikase sesa përdorimi i bravave. Mos harroni të lini komentet tuaja më poshtë.