• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
JavaZone 2009 lyntale - STM
 

JavaZone 2009 lyntale - STM

on

  • 696 views

Norwegian presentation. Lightning talk at JavaZone 2009. Software transactional memory in Java using Deuce.

Norwegian presentation. Lightning talk at JavaZone 2009. Software transactional memory in Java using Deuce.

Statistics

Views

Total Views
696
Views on SlideShare
688
Embed Views
8

Actions

Likes
0
Downloads
0
Comments
0

2 Embeds 8

http://www.linkedin.com 6
http://www.slideshare.net 2

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Hei, I heite Eirik Torske, og jobba på BBS. I våres så kom i over et interessant lite open-source prosjekt. Det er Deuce – en Java-implementasjon av (såkalt) Software Transactional Memory.
  • Software Transtactional Memory – heretter bare kalt S.T.M. – e en mekanisme for samtidig adgang til delte ressurser – altså, samtidighetskontroll . Og som vi alle veit: Samtidighetskontroll blir stadig viktigere i vår multi-core hverdag! STM handle om: utfør en definert kodeblokk – på et definert tidspunkt, se om det har gått bra – hvis ikke, rull tilbake alle endringer utført i kodeblokken, og prøv igjen. Detta e også kalt optimistisk låsing – og e analogt med det vi kjenna fra relasjonsdatabasesystema. Java har støtte for låsbasert samtidighetskontroll – pessimistisk låsing … og no vi ska se litt nærmere på forskjellan mellom dissa to mekanisman.
  • Det handla om samtidighetsproblematikk – og I ska illustrere detta via det klassiske domenet: en pengeoverføring Her e den…
  • … med en tilhørende naiv implementasjon – pengan flyttes fra en fra-konto til en til-konto… en atomisk operasjon
  • Her er den naive implementasjonen av kontoen ->
  • One-liners inni deposit og withdraw ser veldig atomisk ut, men ->
  • … -> hvis vi ser på byte-koden til den naive konto-implementasjonen, ser vi at detta langt ifra e atomisk
  • Vi må legge på samtidighetskontroll for at dette skal fungere i nåkkå anna enn strengt single-threadede miljøer. Java støtter kun pessimistisk låsing out-of-the-box.
  • … for eksempel via denna pakken, som tilbyr et API for å begrense adgang til kodeblokker, altså låsing – og det på en meir fleksibel måte enn hva for eksempel synchronized –nøkkelordet gjør.
  • Her er en låsbasert pengeoverføring. I tillegg til involverte kontoa og beløp, har denne pengeoverføringsimplementasjonen også en Lock (en ReadWriteLock sådan) – og den legges rundt withdraw og deposit ., som e den kritiske regionen. Men det e ikkje nok!
  • - > Vi må også bruke samme lock til å låse alle åpne tilgjengelige tilstandsendrende metoder i konto-klassen. (Lock-implementasjonene i java.util.concurrency.locks-pakken er såkat reentrant – det vil si at hvis en tråd kun legger beslag på en lås én eneste gang, også om den eksplisitt blir bedt om å gjøre det flere ganger. Så den unngår å gå i dead-lock med seg selv – nåkkå som e fole unødvendig…)
  • Poenget mitt e at programmering med Locks ikke er trivielt, og har mange problemer/utfordringer
  • Vi kunne jo også distribuert låsen inn som en del av withdraw/deposit-metodene – men det forkludre modellen!
  • Poenget mitt e at programmering med Locks ikke er trivielt, og har mange problemer/utfordringer
  • Her har ikke MoneyTransfer sin egen lås, men basere se kun på Account-objektene sine – atomisiteten er ivaretatt. Denna koden funka i testan mine, men I syns nå at detta ser ut som ganske dead-lock-utsatt kode… Man tar en lås, for så vente på en anna en…
  • Poenget e at programmering med Locks ikkje e triviell.
  • SÅ, Software Transactional Memory, heretter kun kalt STM derimot…
  • I har kjørt to tester per implementasjon, dem røde kolonnan e testa med påtvungen trådskifte på verst tenkelige tidspunkt – blå kolonne e uten innblanding. Detta e test-kjøringa med ekstrem ”contention”.
  • Scenarioet der STM egna se e nåe man har et stort antall objekter som man jobbe mot. Da blir samtidighetskonflikter unntaket. Med kun én tråd så her STM bare overhead, men allerede med to tråder så bedra dette se … dessverre har ikkje laptopen her mer enn to kjerna – så flere tråder har I ikkje prøvd
  • Hvis dokker synes STM (og andre alternative samtidighetsmekanismer) høres interessant – gå å hør på Jonas Bonér i morgen – han tar opp STM mm – og setter skapet på plass med tanke på når STM egna se og ikkje!

JavaZone 2009 lyntale - STM JavaZone 2009 lyntale - STM Presentation Transcript

  • Software Transactional Memory (STM) … i Java (the language) JavaZone 2009
  • JavaZone 2009 - lyntale
    • Software Transactional Memory (STM)
    • (…i Java the language)
  • JavaZone 2009 - STM
    • In computer science , software transactional memory (STM) is a concurrency control mechanism analogous to database transactions for controlling access to shared memory in concurrent computing .
    • It functions as an alternative to lock-based synchronization .
    • A transaction in this context is a piece of code that executes a series of reads and writes to shared memory. These reads and writes logically occur at a single instant in time; intermediate states are not visible to other (successful) transactions.
    • -Wikipedia
  • JavaZone 2009 - STM
    • /**
    • * A <i>money transfer</i> (a.k.a. “payment”/”transaction”).
    • */
    • public interface MoneyTransfer {
    • void transfer ();
    • }
    En pengeoverføring
  • JavaZone 2009 - STM
    • public class NaiveMoneyTransfer implements MoneyTransfer {
    • protected Account fromAccount;
    • protected Account toAccount;
    • protected long amount;
    • @Override
    • public void transfer () {
    • this.fromAccount.withdraw(this.amount);
    • this.toAccount.deposit(this.amount);
    • }
    • }
    En pengeoverføring – naiv implementasjon
  • JavaZone 2009 - STM
    • public class NaiveAccount implements Account {
    • protected String accountNumber;
    • protected long balance;
    • public void deposit (Long amount) {
    • this.balance += amount;
    • }
    • public void withdraw (Long amount) {
    • this.balance -= amount;
    • }
    • }
    En konto – naiv implementasjon
  • JavaZone 2009 - STM
    • public class NaiveAccount implements Account {
    • protected String accountNumber;
    • protected long balance;
    • public void deposit (Long amount) {
    • this.balance += amount;
    • }
    • public void withdraw (Long amount) {
    • this.balance -= amount;
    • }
    • }
    En konto – naiv implementasjon
  • JavaZone 2009 - STM
    • javap -c ./target/classes/NaiveAccount
    • public void deposit(int);
    • Code:
    • 0: aload_0
    • 1: dup
    • 2: getfield #3; //Field balance:I
    • 5: iload_1
    • 6: iadd
    • 7: putfield #3; //Field balance:I
    • 10: return
    • public void withdraw(int);
    • Code:
    • 0: aload_0
    • 1: dup
    • 2: getfield #3; //Field balance:I
    • 5: iload_1
    • 6: isub
    Ikke atomisk
  • JavaZone 2009 - STM
    • javap -c ./target/classes/NaiveAccount
    • public void deposit(int);
    • Code:
    • 0: aload_0
    • 1: dup
    • 2: getfield #3; //Field balance:I
    • 5: iload_1
    • 6: iadd
    • 7: putfield #3; //Field balance:I
    • 10: return
    • public void withdraw(int);
    • Code:
    • 0: aload_0
    • 1: dup
    • 2: getfield #3; //Field balance:I
    • 5: iload_1
    • 6: isub
    Ikke atomisk Kontekstsvitsjing mellom disse stedene vil gi ”lost update”
  • JavaZone 2009 - STM Samtidighetskontroll
  • JavaZone 2009 - STM java.util.concurrent.locks
  • JavaZone 2009 - STM
    • import java.util.concurrent.locks.ReadWriteLock;
    • public class LockedNaiveMoneyTransfer implements MoneyTransfer {
    • private ReadWriteLock moneyTransferLock;
    • @Override
    • public void transfer() {
    • this.moneyTransferLock.writeLock().lock();
    • try {
    • this.fromAccount.withdraw(this.amount);
    • this.toAccount.deposit(this.amount);
    • } finally {
    • this.moneyTransferLock.writeLock().unlock();
    • }
    • }
    • }
    En lock-basert pengeoverføring
  • JavaZone 2009 - STM
    • import java.util.concurrent.locks.ReadWriteLock;
    • public class LockedAccount implements Account {
    • private ReadWriteLock accountLock;
    • @Override
    • public void deposit(Long amount) {
    • accountLock.writeLock().lock();
    • try {
    • this.balance += amount;
    • } finally {
    • accountLock.writeLock().unlock();
    • }
    • }
    • @Override
    • public void withdraw(Long amount) { … }
    • }
    En lock-basert konto
  • JavaZone 2009 - STM
    • Boilerplate  mindre vedlikeholdbar kode
    • Må baseres på ad-hoc konvensjoner  error-prone
    • Distribusjon av Lock s  forkludrer modellen
    Problemer ved pessimistisk låsing
  • JavaZone 2009 - STM
    • import java.util.concurrent.locks.ReadWriteLock;
    • public class LockedAccountImpl implements LockedAccount {
    • @Override
    • public void deposit(Long amount, ReadWriteLock accountLock ) {
    • accountLock.writeLock().lock();
    • try {
    • this.balance += amount;
    • } finally {
    • accountLock.writeLock().unlock();
    • }
    • }
    • @Override
    • public void withdraw(Long amount, ReadWriteLock accountLock ) { … }
    • }
    En lock-basert konto
  • JavaZone 2009 - STM
    • Boilerplate  mindre vedlikeholdbar kode
    • Må baseres på ad-hoc konvensjoner  error-prone
    • Distribusjon av Lock s  forkludrer modellen
    • Én eneste lås  veldig ineffektivt
      • Kun én eneste pengeoverføring om gangen, uansett hvilke kontoer som er involvert
      • Ekstremt resurssløsende for flertrådsmiljøer
    Problemer ved pessimistisk låsing
  • JavaZone 2009 - STM
    • import java.util.concurrent.locks.ReadWriteLock;
    • public class MultiLockedMoneyTransfer implements MoneyTransfer {
    • @Override
    • public void transfer() {
    • this.fromAccount.getAccountLock().writeLock().lock();
    • this.toAccount.getAccountLock().writeLock().lock();
    • try {
    • this.fromAccount.withdraw(this.amount);
    • this.toAccount.deposit(this.amount);
    • } finally {
    • this.toAccount.getAccountLock().writeLock().unlock();
    • this.fromAccount.getAccountLock().writeLock().unlock();
    • }
    • }
    • }
    En mer effektiv lock-basert pengeoverføring (multi-lock)
  • JavaZone 2009 - STM
    • Boilerplate  mindre vedlikeholdbar kode
    • Må baseres på ad-hoc konvensjoner  error-prone
    • Distribusjon av Lock s  forkludrer modellen
    • Én eneste lås  veldig ineffektivt
      • Kun én eneste pengeoverføring om gangen, uansett hvilke kontoer som er involvert
      • Ekstremt resurssløsende for flertrådsmiljøer
    • Flere låser  effektivt, men veldig komplisert
      • Algoritme for hvilken lås som til enhver tid skal benyttes
      • … og den algoritmen bør være effektiv så ikke vinningen går opp i spinningen 
        • korrekt lås
        • korrekt rekkefølge på låser
        • recovery ved feil
        • timeouts
    Problemer ved pessimistisk låsing
  • JavaZone 2009 - STM
    • Optimistisk låsing, ekte samtidighet
    • Automatisk retry ved konflikter
    • Semantisk mer komplett
      • enklere programmeringsmodell, abstraherer bort kritiske regioner
      • orientert mot tilstandsendringer , ikke mot kodeblokker
    Software Transactional Memory (STM)
  • JavaZone 2009 - STM
    • En forsøk på en slags ”commit-time locking” algoritme…
    • Ved load-time: Instrumenter alle aktuelle tilstandsendringer i alle relevante klasser
    • Ved run-time: Opprett en ThreadLocal-basert transaksjonskontekst
      • Logg alle reads
      • Ta vare på alle verdier for writes
    • Ved committ, lås det som trengs, sjekk alle andre aktive transaksjonskontekster om dirty reads er forekommet
      • Hvis ja, retry eller kast en exception
      • Hvis nei, skriv alle mellomlagrede write-verdier til de ekte objektene
    • Fjern alle avsluttede transaksjonskontekster
    Software Transactional Memory (STM) – How do they do it!?
  • JavaZone 2009 - STM
    • Java-implementasjon av STM
    • Basert på annotations
      • @Atomic(retries = n)
      • @Exclude (Fritak fra bytecode-manipulering)
    • Benytter java.lang.instrument –pakken og ASM til å manipulere bytecode dynamisk
    Deuce http://www.deucestm.org
  • JavaZone 2009 - STM
    • import org.deuce.Atomic;
    • public class DeuceStmMoneyTransfer implements MoneyTransfer {
    • @Override
    • @Atomic
    • public void transfer() {
    • this.fromAccount.withdraw(this.amount);
    • this.toAccount.deposit(this.amount);
    • }
    • }
    En Deuce-basert pengeoverføring
  • JavaZone 2009 - STM
    • import org.deuce.Atomic;
    • public class LockedAccount implements Account {
    • @Override
    • @Atomic
    • public void deposit(Long amount) {
    • this.balance += amount;
    • }
    • @Override
    • @Atomic
    • public void withdraw(Long amount) {
    • this.balance -= amount;
    • }
    • }
    En Deuce-basert konto
  • JavaZone 2009 - STM
  • JavaZone 2009 - STM
  • JavaZone 2009 - STM
  • JavaZone 2009 - STM
    • +
    • Enkelt å bruke
    • Forenkler koden betraktelig
    • Ser ut til å funke
    • Kjappere enn pessimistisk låsing… når forholdene ligger til rette
    Deuce
    • Stor avstand mellom kode og kjørende system
    • Flere kritiske røster…
    • Umodent?
  • JavaZone 2009 - STM
    • java -Xms64m -Xmx64m
    • -javaagent:”%M2_REPO%orgdeucedeuceAgent1.0.0deuceAgent-1.0.0.jar”
    • -Dorg.deuce.verbose=true
    • -Dorg.deuce.transaction.contextClass=org.deuce.transaction.tl2.Context
    • -Dorg.deuce.exclude=&quot;java.*,sun.*,org.*,junit.*,net.*”
    • -cp &quot;%M2_REPO%orgdeucedeuceAgent1.0b5deuceAgent-1.0b5.jar;
    • target/test-classes;
    • target/classes;
    • %M2_REPO%commons-langcommons-lang2.4commons-lang-2.4.jar;
    • %M2_REPO%junitjunit4.5junit-4.5.jar;
    • %M2_REPO%log4jlog4j1.2.14log4j-1.2.14.jar;
    • %M2_REPO%orgslf4jslf4j-api1.5.6slf4j-api-1.5.6.jar;
    • %M2_REPO%orgslf4jslf4j-log4j121.5.6slf4j-log4j12-1.5.6.jar&quot;
    • no.bbs.training.stm.MoneyTransferTestRunner
    Deuce
  • JavaZone 2009 - STM
    • http://www. deuce stm.org/
    • http://www. xstm .net
    • http://code.google.com/p/ multiverse /
    Prosjekter – STM i Java the language
  • JavaZone 2009 - STM
    • http://en.wikipedia.org/wiki/Software_transactional_memory
    • http://en.wikipedia.org/wiki/Lock_(computer_science)
    • http://en.wikipedia.org/wiki/ACID
    • http://www.deucestm.org/
    • http://www.xstm.net
    • http://www.codecommit.com/blog/scala/software-transactional-memory-in-scala
    • http://www.slideshare.net/jboner/state-youre-doing-it-wrong-javaone-2009
    • http://clojure.org/refs
    • http://groups.google.com/group/clojure/browse_thread/thread/5c7a962cc72c1fe7?pli=1
    Kilder
  • www.bbs.no