akka-STM - opinie
Mirek Pluta
Bardzo mnie zainteresowal temat zwiazany z pamiecia transakcyjna,
ktore to haslo padlo w czasie naszego ostatniego spotkania.
Musze sie przyznac, ze wczesniej nie slyszalem o tym modelu.
Zaczałem wiec czytac i szukac roznych informacji.
Zaczałem od http://www.codecommit.com/blog/scala/software-transactional-memory-in-scala
tego wpisu, ktory wedlug mnie swietnie tlumaczy idee pamieci
transakcyjnej oraz typowy sposob jej implementacji ( szkoda, ze system
operacyjny czegos takiego nie oferuje, tylko trzeba uciekac sie do
rozwiazan na poziomie biblioteki ).
Idac dalej po sznurku trafilem do klebka nazwanego akka-stm i musze
przyznac ze spodobalo mi sie to rozwiazanie.
Jako, ze jeszcze nie mialem okazji dosc dokladnie przetestowac akka-
stm, wiec tutaj mam kilka pytan do Was:
* Czy ktos ma doswiadczenie z ta biblioteka ( a dokladnie z ta jej
czescia - STM ) ?
* Jesli tak, to jak wyglada sprawa z wydajnoscia, zarowno jesli
chodzi o pamiec jak i CPU ? Wiem, ze na pewno wprowadza to narzut na
zurzycie pamieci, jako ze zmienne proste musza byc zastapione przez
obiekty Ref.
* Jaki wplyw na wydajnosc ma laczenie "blokow atomicznych" ? Tzn: Mam
dwie klasy, ktorych wszystkie metody mam zadeklarowane jako atomiczne
i wywoluje metody jednej z tych klas z drugiej:
class A{
def m() = atomic { .... }
}
class B{
def n() = atomic { refDoA.m }
}
Czy to ma gorsza wydajnosc, niz gdyby np tylko metody w B byly
zadeklarowane jako atomiczne ?
* Jesli dobrze zrozumialem, to jest to rozwiazanie po czesci all-or-
nothing, tzn, jesli mamy metode atomiczna, to wszystko co ona wywola
tez musi byc atomiczne ( lub nie moze miec stanu, ktory zostanie
zmodyfikowany ), ze wzgledu na to, ze transakcje moga byc powtorzone w
razie problemu, wiec nie chcemy dwa razy zmieniac stanu. Czy w takim
przypadku dobre jest podejscie, w ktorym wszystkie kluczowe obiekty
maja metody atomiczne ?
* Jakie spotkaliscie problemy/jakie macie spostrzezenia/doswiadczenia/
wskazowki zwiazane z wykorzystaniem STM ?
pozdrawiam, Mirek
Przemyslaw Pokrywka
Sam niestety nie używałem jeszcze, więc dużo nie powiem. Jonas Boner
na slajdach z JavaOne poleca użycie STM w sytuacjach podobnych, jak
omawiany na spotkaniu przypadek przelewu bankowego. Na spotkaniu widać
było, że model aktorów nie jest dobrym wyborem do tego problemu. STM
powinien nadać się lepiej (być może jest nawet do tego optymalny).
Trudno mi odpowiedzieć na konkretne pytania. Myślę, że problematykę
STM świetnie zdążyli przećwiczyć użytkownicy Clojure, w którym STM
jest dostępny na starcie bez dodatkowych bibliotek - można poszukać
coś w części Sieci poświęconej temu językowi.
Sam wiem tylko jeszcze, że w Scali dostępna jest poza Akką ciekawa
biblioteka CCSTM, której prezentacja na Scala Days (dostępna też w
necie) bardzo mi się spodobała. Oferuje ona STM bez wymagania użycia
aktorów (w Akka chyba do użycia STM konieczne jest użycie tzw
"transactors", chyba że patrzyłem byle jak albo coś się tam już
zmieniło - wiem z Twittera, że Viktor Klang jest bardzo zadowolony z
najnowszego kodu dotyczącego STM w Akka).
O ile się orientuję, STM wiąże się z użyciem dodatkowej pamięci
(wrappery oraz chyba też pamiętanie poszczególnych wersji wartości)
oraz czasu procesora na operacje na tych obiektach, rollbacks i
retries transakcji.
Pozdrawiam
Przemek
W dniu 13 listopada 2010 19:59 użytkownik Mirek Pluta
<lun...@gmail.com> napisał:
> --
> Otrzymujesz tę wiadomość, ponieważ subskrybujesz grupę dyskusyjną Google o nazwie "WrASSE".
>
> Aby zamieszczać posty w tej grupie, wyślij e-mail na adres wroclaw-scal...@googlegroups.com.
> Aby anulować subskrypcję tej grupy, wyślij e-mail na adres wroclaw-scala-enth...@googlegroups.com.
> Aby uzyskać więcej informacji, odwiedź tę grupę pod adresem http://groups.google.com/group/wroclaw-scala-enthusiasts?hl=pl.
>
>