mboost-dp1
Sun
Nogen der kan komme med et eksempel hvor den optimale løsning ikke bare er en database med transaktionsstyring (noget vi vel har haft siden 1970erne) eller er hans bank eksempel blot et teknisk eksempel?
Hvad er forskellen fra det her og de "locks" vi kender fra eksisterende programmering? De lader da til at have samme formål med at låse en variabel ned så man netop ikke kommer til at læse eller skrive til den på det forkerte tidspunkt.
Hvad er forskellen fra det her og de "locks" vi kender fra eksisterende programmering? De lader da til at have samme formål med at låse en variabel ned så man netop ikke kommer til at læse eller skrive til den på det forkerte tidspunkt.
Jeg kender ikke den implementation der er beskrevet her, men formålet med transaktionel memory er at få et konsistent snapshot af hvordan tilstanden ser ud, når man starter transaktionen.
Ved at bruge låse så kan man låse begrænsede portioner af ens data, så de ikke kan tilgås af andre tråde. Det kan betyde at performancen bliver degraderet fordi tråd 2 er nødt til at vente på at tråd 1 bliver færdig, før den kan fortsætte. I uheldige tilfælde risikerer man også en deadlock når to tråde venter på hinanden.
Bruges transaktionel memory vil hver tråd ikke låse sine data, men have et snapshot af hvordan data så ud da transaktionen blev startet.
Ved at bruge låse så kan man låse begrænsede portioner af ens data, så de ikke kan tilgås af andre tråde. Det kan betyde at performancen bliver degraderet fordi tråd 2 er nødt til at vente på at tråd 1 bliver færdig, før den kan fortsætte. I uheldige tilfælde risikerer man også en deadlock når to tråde venter på hinanden.
Bruges transaktionel memory vil hver tråd ikke låse sine data, men have et snapshot af hvordan data så ud da transaktionen blev startet.
Fordelen her er to ting:
#1 I forhold til traditionel locking bruger man her i stedet "roll back" hvis man, EFTER at man har lavet ændringer, opdager at andre har pillet i data. Det giver naturligvis et overhead, men det er åbenbart sådan i praksis at den tid som spildes på roll back er mindre end den tid som spildes på at vente på låse. (Jeg kunne forestille mig at denne fordel kan diskuteres. Det afhænger nok af opgaven osv.)
#3 Med sådan et framework kan man netop blot skrive sine programmer uden at selv at skulle bekymre sig om at kode selve "låsedelen". Det er nu som regel bedst at lade dem, som er bedst til en opgave, løse den.
#1 I forhold til traditionel locking bruger man her i stedet "roll back" hvis man, EFTER at man har lavet ændringer, opdager at andre har pillet i data. Det giver naturligvis et overhead, men det er åbenbart sådan i praksis at den tid som spildes på roll back er mindre end den tid som spildes på at vente på låse. (Jeg kunne forestille mig at denne fordel kan diskuteres. Det afhænger nok af opgaven osv.)
#3 Med sådan et framework kan man netop blot skrive sine programmer uden at selv at skulle bekymre sig om at kode selve "låsedelen". Det er nu som regel bedst at lade dem, som er bedst til en opgave, løse den.
ghostface (1) skrev:Nogen der kan komme med et eksempel hvor den optimale løsning ikke bare er en database med transaktionsstyring (noget vi vel har haft siden 1970erne) eller er hans bank eksempel blot et teknisk eksempel?
Hvad er forskellen fra det her og de "locks" vi kender fra eksisterende programmering? De lader da til at have samme formål med at låse en variabel ned så man netop ikke kommer til at læse eller skrive til den på det forkerte tidspunkt.
Transaktionsstyring er faktisk et godt eksempel.
På en konto er der 100 kr. Der bliver så udført 5 transaktioner på samme tid. Med almindelige locks bliver dataene låst til én transaktion per gang og saldoen beregnes:
T1: -50kr (50kr)
T2: +10kr (60kr)
T3: -40kr (20kr)
T4: -70kr (-50kr) Denne transaktion fejler fordi kontoen vil gå i minus
T5: +50kr (0kr)
Med Multiverse opstår dette problem ikke. Her kan flere transaktioner tilgå dataene på samme tid. Inden transaktionerne afsluttes kontrollerer de med de øvrige transaktioner om dataene stadig er gyldige:
T1: -50kr (100kr)
T2: +10kr (100kr)
T3: -40kr (100kr)
T4: -70kr (100kr)
T5: +50kr (100kr)
Kontrollen kan se således ud:
100 + ((-50) + (10) + (-40) + (-70) + (50)) >= 0
Hvis kontrollen fejler bliver der lavet et rollback på dataene og transaktionerne afvikles igen, men med en prioritering på hver transaktion således at så mange som muligt af transaktionerne gennemføres.
Det er i hvert fald sådan jeg har forstået Multiverse.
Tråd-synkronisering er ofte dyrere end man lige skulle tro - det kan degradere performance gevaldigt, og ødelægger scalability. Derudover er synkronisering svært når man bevæger sig udover trivielle eksempler.
#1: bankoverførslen her skal nok blot tænkes som et eksempel; banktransaktioner vil have en database indover for at have persistance. Der hvor STM vinder er in-memory operationer med en del reads og relativt få writes.
#1: bankoverførslen her skal nok blot tænkes som et eksempel; banktransaktioner vil have en database indover for at have persistance. Der hvor STM vinder er in-memory operationer med en del reads og relativt få writes.
mireigi (5) skrev:
Med Multiverse opstår dette problem ikke. Her kan flere transaktioner tilgå dataene på samme tid. Inden transaktionerne afsluttes kontrollerer de med de øvrige transaktioner om dataene stadig er gyldige:
T1: -50kr (100kr)
T2: +10kr (100kr)
T3: -40kr (100kr)
T4: -70kr (100kr)
T5: +50kr (100kr)
Kontrollen kan se således ud:
100 + ((-50) + (10) + (-40) + (-70) + (50)) >= 0
Hvis kontrollen fejler bliver der lavet et rollback på dataene og transaktionerne afvikles igen, men med en prioritering på hver transaktion således at så mange som muligt af transaktionerne gennemføres.
Det er i hvert fald sådan jeg har forstået Multiverse.
Dit eksempel er ikke helt korrekt i forhold til hvordan TM normalt er implementeret. TM er opbygget over et koncept med transactions, kraftigt inspireret af hvordan databaser fungerer. En transaction opererer på et sæt inputdata, laver nogle beregninger og commiter resultatet til hukommelsen. En transaction skal opfattes som atomisk. Dvs. at transaction fejler, hvis en anden transaction har pillet ved inputdata undervejs. Der findes en række forskellige måder at detektere konflikter i forbindelse med transactions. Generelt tager man et snapshot af alle inputdata til en transaction før den udføres. Skulle det så ske at nogle ændringer af inputdata er ændret i det øjeblik hvor en transaction committes, vil transaction'en fejle og den må foretages på ny.
Det vil sige at dit eksempel vil alle transactions på nær en, fejle i første forsøg. Idet den første committer sit resultat, vil resten fejle, da inputdata er ændret. De må så starte forfra. Så resultatet er det samme som hvis det var lavet med locks og tråde.
Filosofien bag TM er fin nok, men personligt tror det er en død sild. Der er en række fundamentale problemer. F.eks. er det umuligt at håndtere I/O i transactions og nestede transactions er heller ikke let. STM er desuden langsomt. Sun arbejdede på hardware support for TM i deres kommende Rock processor. Den kommer vist aldrig på markedet efter Oracles opkøb.
Syntes faktisk eksemplet med bank er ret dårligt. Dette vil næppe blive brugt i backend af banksystem eller det har jeg i hvert fald svært ved at forestille mig (der vil man enten bruge noget andet eller have andre mekanismer til at sørge for at pengetransaktionerne er atomare). Det tætteste jeg kan komme er måske en eller en anden form for hjemmebank application/budget beregner el. lignende. Men hvorfor køre flertrådet på denne måde i den type app. har jeg svært ved at se.
Kom med et eksempel hvor dette rent faktisk vil kunne anvendes med fordel fremfor traditionel låsning. Hvor med fordel forståes bedre performance eller nemmere at lave korrekt.
Kom med et eksempel hvor dette rent faktisk vil kunne anvendes med fordel fremfor traditionel låsning. Hvor med fordel forståes bedre performance eller nemmere at lave korrekt.
#8 Jeg kan godt lide at du kalder synkroniseringsproblemer for simple ting alle "ordentlige" kodere skal kunne lave.
Det viser total mangel på indsigt og viden i området.
Der er en grund til at der er så (relativt) lidt understøttelse for multikerne systemer i applikationer, og det er simpelthen synkroniserings problematikken som er voldsomt kompleks.
Det viser total mangel på indsigt og viden i området.
Der er en grund til at der er så (relativt) lidt understøttelse for multikerne systemer i applikationer, og det er simpelthen synkroniserings problematikken som er voldsomt kompleks.
darune (9) skrev:Kom med et eksempel hvor dette rent faktisk vil kunne anvendes med fordel fremfor traditionel låsning. Hvor med fordel forståes bedre performance eller nemmere at lave korrekt.
Ideen i TM er sådan set fin nok. Man skal ikke tænke på låse overhovedet. Alt bliver håndteret med transactions, som er rimeligt simple at forstå. Fordelen ved TM skal findes i applikationer der kræver mange låse, som kun er nødvendige for undgå meget sjældne race-conditions. Altså låse der sjældent er konflikt omkring. Har du f.eks. en billedbehandlingsalgoritme der med flere tråde arbejder på forskellige område at et billede, kan det være svært at opdele billedet i fornuftige dele der kan tilknyttes en lås. Bruger man TM, skal man ikke bekymre sig om at to tråde skulle skrive i de samme pixels i billedet. Sker det engang imellem, vil den ene transaction bare fejle og den vil blive lavet en gang til.
Det er selvfølgelig ikke gratis når transactions fejler. Derfor skal det helst ikke ske for tit.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund