Forum » Programiranje » [c++] Thread safe?
[c++] Thread safe?
zhigatsey ::
Živjo,
Ko berem sem pa tja kakšen članek, velikokrat zasledim,
ko ljudje sprašujejo ali je razred "thread safe" in podobno...
Kaj to sploh točno pomeni... Če jaz napišem čisto enostaven
razred v cpp ali je thread safe ali ni. Torej če ni, ga ni varno uporabljati
v nitih, ker lahko iz druge niti lahko spreminjaš njegove vrednosti?
In kaj moraš sploh narediti, da je tvoj razred thread safe?
Če lahko kdo malo razjasni...
Hvala za odgovore
Ko berem sem pa tja kakšen članek, velikokrat zasledim,
ko ljudje sprašujejo ali je razred "thread safe" in podobno...
Kaj to sploh točno pomeni... Če jaz napišem čisto enostaven
razred v cpp ali je thread safe ali ni. Torej če ni, ga ni varno uporabljati
v nitih, ker lahko iz druge niti lahko spreminjaš njegove vrednosti?
In kaj moraš sploh narediti, da je tvoj razred thread safe?
Če lahko kdo malo razjasni...
Hvala za odgovore
Gundolf ::
Thread safety ni ravno enostavna tema, da bi se jo dalo razložiti v dveh stavkih. Preberi raje še kakšen članek :)
Po defaultu praktično noben ne-trivialen razred ni thread-safe. To pomeni, da objektov tega razreda ni varno nezaščitenega uporabljati v dveh nitih hkrati. Kar pa ponavadi ni nek problem, da bi šel vse svoje razrede delat thread-safe, raje jih zaščitiš kasneje, ko jih dejansko rabiš v večih nitih. Ta, kasnejša zaščita se sploh da v c++ zelo elegantno narest.
Po defaultu praktično noben ne-trivialen razred ni thread-safe. To pomeni, da objektov tega razreda ni varno nezaščitenega uporabljati v dveh nitih hkrati. Kar pa ponavadi ni nek problem, da bi šel vse svoje razrede delat thread-safe, raje jih zaščitiš kasneje, ko jih dejansko rabiš v večih nitih. Ta, kasnejša zaščita se sploh da v c++ zelo elegantno narest.
Vesoljc ::
ja, thread safety ni enostavna zadeva (se posebaj ko rabis performance). osnovna logika pravi, da do enega kosa pomnilnika ob danem trenutku, ne sme dostopati vec niti, vkolikor vsaj ena izmed njih pise (Write), saj ostali bralci (Read) lahko dobijo pokvarjene podatke. da dva threada ne smeta imeti W-operacij na istem kosu pomnilnika je pa tak tak jasno, nee? :)
eden izmed primitivov za zascito je lock, ki je zgrajen okoli atomske opearcije (garantirano se izvede v enem ciklu - torej se je ne da prekiniti, compare&swap). tak lock ponavadi vzame kot kljuc id threada, iz katerega dostopas. ce je v kljucavnici ze nekdo z drugacnim kljucem, moras ti pocakati, dokler jo le-ta ne sprosti (blocking). lock lahko potem se nadgradis z tipom operacije (W,R), tako da lahko lock dovoli vec hkratnih R-operacij iz razlicnih threadov (kar je legalno).
gundolf ima prav, ko pravi, da ima c++ lahko zelo elegantne resitve za take probleme. meni je recimo prekleto vsec scoped locking. :)
je pa tako kot povsod, po toci zvoniti je bolj tko tko. vkolikor ne mislis naprej (bom rabil vec threadov?) se stvari znajo precej zakomplicirat, ce nisi pazljiv seveda.
vedi pa, da je debuging vec nitne aplikacij precej zaje.... stvar, saj zelo tezko dobis ponovljiva stanja. ce ti app kresne ob vsakem zagonu, ni problema, pac postavis breakpoint in gres skozi, ce pa ti kresne vsakih 100 runov...
mislim da je v temi c++ povezave, kar ene par linkov, ki bolj natancno razlozijo zadevo.
eden izmed primitivov za zascito je lock, ki je zgrajen okoli atomske opearcije (garantirano se izvede v enem ciklu - torej se je ne da prekiniti, compare&swap). tak lock ponavadi vzame kot kljuc id threada, iz katerega dostopas. ce je v kljucavnici ze nekdo z drugacnim kljucem, moras ti pocakati, dokler jo le-ta ne sprosti (blocking). lock lahko potem se nadgradis z tipom operacije (W,R), tako da lahko lock dovoli vec hkratnih R-operacij iz razlicnih threadov (kar je legalno).
gundolf ima prav, ko pravi, da ima c++ lahko zelo elegantne resitve za take probleme. meni je recimo prekleto vsec scoped locking. :)
je pa tako kot povsod, po toci zvoniti je bolj tko tko. vkolikor ne mislis naprej (bom rabil vec threadov?) se stvari znajo precej zakomplicirat, ce nisi pazljiv seveda.
vedi pa, da je debuging vec nitne aplikacij precej zaje.... stvar, saj zelo tezko dobis ponovljiva stanja. ce ti app kresne ob vsakem zagonu, ni problema, pac postavis breakpoint in gres skozi, ce pa ti kresne vsakih 100 runov...
mislim da je v temi c++ povezave, kar ene par linkov, ki bolj natancno razlozijo zadevo.
Abnormal behavior of abnormal brain makes me normal...
Matako ::
Thread-safe se ne nanaša samo na razrede! Enostavno povedano, "thread-safe" funkcija (podprogram karkoli) je tista, ki deluje enako ne glede če se jo hkrati uporablja (kliče) iz več niti.
Kako to doseči je dolga zgodba in v bistvu ni vedno najbolj enostavno ugotoviti.
V splošnem sta dve znani finti. Prva je, da je koda popolnoma "reeentrant", to pomeni, da če jo začne izvajati neka druga nit, potem ko že teče znotraj prve ostane vse ok. V tem primeru lahko recimo kar pozabiš na kake statične in globalne spremenljivke razen ...
2. ... če zaklepaš na veliko. Skrajni ampak sploh ne tako zelo neuporaben koncept je da takoj na začetku zasežeš semafor in ga čisto na koncu sprostiš. Če uleti sedaj druga nit, bo morala takoj na začetku čakati, da pride prva do konca. Performančno gledano bolj tako-tako, dela pa. Potem lahko stavar od tukaj naprej optimiziraš da kritični del ožaš (nakar tipično enkrat fašeš deadlock ali kaj še bolj čudnega).
Glede vračanja rezultatov pa mora nit, ki kliče nekako podati referenco na SVOJE podatke.
Kako to doseči je dolga zgodba in v bistvu ni vedno najbolj enostavno ugotoviti.
V splošnem sta dve znani finti. Prva je, da je koda popolnoma "reeentrant", to pomeni, da če jo začne izvajati neka druga nit, potem ko že teče znotraj prve ostane vse ok. V tem primeru lahko recimo kar pozabiš na kake statične in globalne spremenljivke razen ...
2. ... če zaklepaš na veliko. Skrajni ampak sploh ne tako zelo neuporaben koncept je da takoj na začetku zasežeš semafor in ga čisto na koncu sprostiš. Če uleti sedaj druga nit, bo morala takoj na začetku čakati, da pride prva do konca. Performančno gledano bolj tako-tako, dela pa. Potem lahko stavar od tukaj naprej optimiziraš da kritični del ožaš (nakar tipično enkrat fašeš deadlock ali kaj še bolj čudnega).
Glede vračanja rezultatov pa mora nit, ki kliče nekako podati referenco na SVOJE podatke.
/\/\.K.
Zgodovina sprememb…
- spremenil: Matako ()
Vredno ogleda ...
Tema | Ogledi | Zadnje sporočilo | |
---|---|---|---|
Tema | Ogledi | Zadnje sporočilo | |
» | [C#] - .ocx, Access violationOddelek: Programiranje | 686 (546) | mihies |
» | Učenje programiranja (strani: 1 2 )Oddelek: Programiranje | 18190 (14793) | Spura |
» | c# debugger noce ujeti exceptiona!!Oddelek: Programiranje | 1493 (1164) | BlueRunner |
» | VB.NET...al pa C#Oddelek: Programiranje | 1264 (1179) | frudi |
» | Desktop aplikacije večinoma niso multithreaded??? (strani: 1 2 )Oddelek: Programiranje | 4880 (4126) | Gundolf |