Cilat lloje të të dhënave janë të sigurta për t'u lexuar dhe shkruar pas marrjes së tyre nga një strukturë e aksesueshme njëkohësisht?

Ju keni të drejtë duke supozuar se këto lloje të të dhënave, kryesisht referencat dhe treguesit e strukturave mund të shkaktojnë një problem për arsyet për të cilat do të flas më poshtë.

Unë shoh vërtet dy probleme me të cilat po përballeni. E para, është që ju duhet të mbroni cache-in tuaj nga aksesi i njëkohshëm në mënyrë që cache të jetë gjithmonë në gjendjen e duhur. Nëse po ndryshoni cache dhe përdorni një bllokues "shkrimi", cache juaj do të ruajë integritetin e saj kur të ndryshohet në një farë mënyre. Gjithashtu, për sa kohë që merrni një bllokim "leximi" kur lexoni nga cache, ju garantohet se do të lexoni nga cache juaj me të njëjtin integritet. Pra, siç qëndron tani, bravat që mbrojnë cache-in tuaj punojnë vetëm në mbrojtjen e vetë cache-it. Këto bravë nuk do të bëjnë asgjë për të mbrojtur artikujt e ruajtur në cache.

Kjo është çështja e dytë me të cilën po merreni: Duke supozuar se cache-ja juaj është e mbrojtur, mendoni se çfarë do të ndodhte nëse dy gorutina të veçanta bëjnë një operacion të sinkronizuar siç duhet Get nga cache-ja juaj. Ata as nuk duhet domosdoshmërisht të marrin objektin në të njëjtën kohë, por nëse në një farë mënyre përfundojnë duke "marrë" një tregues për ndonjë strukturë ose një referencë në një hartë/pjesë, kjo do të thotë se ata potencialisht mund të dy të ndryshojnë të njëjtin objekt për të cilat ata të dy mbajnë referenca. Kjo shfaqet si problemi i dytë që po përshkruani.

Pra, cilat janë opsionet tuaja?

1. Vetëm llojet e vlerave të ruajtura të cilat siç e keni vërejtur mund të jenë kufizuese dhe/ose të shtrenjta sepse gjithçka duhet të kopjohet.
2. Ruani vetëm disa lloje të personalizuara që janë të sinkronizuara duke u siguruar gjithashtu që të marrin bravat e duhura mbi veten e tyre kur ato ndryshojnë ose lexohen.
3. Bëjeni cache-në tuaj më të zgjuar në mënyrë që të ketë konceptin e pronësisë ku do të kthejë me kënaqësi një objekt nga cache dhe do të lejojë vetëm një gorutinë të "mbahet" mbi të derisa të përfundojë ajo gorutinë. Gorutina të tjera do të duhet të presin që ai objekt të lëshohet derisa gorutina e mëparshme të përfundojë me të. Ose këtë, ose mund ta dizenjosh Get që të dështojë dhe të kthehet menjëherë nëse përpiqet të marrë një artikull që nuk ishte aktualisht i disponueshëm. Ky koncept përdoret gjerësisht për të ndërtuar bravë të shpërndarë në një arkitekturë të serverit të klientit, ku mund të ketë shumë klientë që duan qasje në një objekt dhe bllokimi i shpërndarë siguron që vetëm një klient mund ta mbajë bllokimin.

Konsideroni se koncepti i pronësisë është i rëndësishëm. Dikush mund të thotë: thjesht përdorni kanale, që do të rregullojnë gjithçka. Por ju madje mund të përfundoni në të njëjtën varkë nëse dërgoni një lloj referimi ose një tregues në një strukturë në 5 kanale të ndryshme. Këto 5 kanale të ndryshme ndoshta mund të ndryshojnë të njëjtin objekt që po mbajnë. Uh Oh! i njëjti problem shfaqet përsëri. Kjo është arsyeja pse është e rëndësishme që kur kaloni një artikull në një kanal, të hiqni dorë nga pronësia për të mos e ndryshuar atë.

Siç më tha dikush sot...programimi i njëkohshëm është i vështirëdhe ndoshta ka modele shtesë që mund t'i provoni, por shpresoj që kjo t'ju japë më shumë informacion mbi problemin me të cilin po trajtoni. Një gjë që duhet të dini është se nuk ka vërtet një përgjigje të qëndrueshme për këtë, shumë prej saj do të varet nga natyra e mënyrës se si do të sillet aplikacioni juaj në fund të fundit.

1) A kam të drejtë duke supozuar se këto lloje të të dhënave paraqesin probleme për një skenar si ky?

Po. Hartat dhe pjesët kanë tregues për strukturat e brendshme të të dhënave që nuk kopjohen gjatë caktimit. Por meqenëse jeni duke përdorur një interface{}, mund të keni edhe struktura me tregues, të cilët mund të tregojnë struktura me më shumë tregues e kështu me radhë.

2) Si mund të shkohet për zgjidhjen e kësaj çështjeje, në mënyrë që të krijohet një metodë Get, vlerat e së cilës mund të manipulohen lirisht pa frikën e dështimit në kushte gare?

Zgjidhja më e lehtë është të lejoni që një objekt t'i kthehet një klienti të vetëm në të njëjtën kohë, në mënyrë që të ketë vetëm një version të drejtpërdrejtë, të ndryshueshëm. Ju gjithashtu mund të serializoni objektet, në mënyrë që gjithçka të jetë gjithmonë një kopje.

Çdo gjë që duhet të shkruhet dhe të lexohet njëkohësisht duhet të ketë sinkronizimin e duhur. Periudha.