What do you think?
Rate this book
Seven Concurrency Models in Seven Weeks: When Threads Unravel
Your software needs to leverage multiple cores, handle thousands of users and terabytes of data, and continue working in the face of both hardware and software failure. Concurrency and parallelism are the keys, and Seven Concurrency Models in Seven Weeks equips you for this new world. See how emerging technologies such as actors and functional programming address issues with traditional threads and locks development. Learn how to exploit the parallelism in your computer's GPU and leverage clusters of machines with MapReduce and Stream Processing. And do it all with the confidence that comes from using tools that help you write crystal clear, high-quality code.
This book will show you how to exploit different parallel architectures to improve your code's performance, scalability, and resilience.
Learn about the perils of traditional threads and locks programming and how to overcome them through careful design and by working with the standard library. See how actors enable software running on geographically distributed computers to collaborate, handle failure, and create systems that stay up 24/7/365. Understand why shared mutable state is the enemy of robust concurrent code, and see how functional programming together with technologies such as Software Transactional Memory (STM) and automatic parallelism help you tame it.
You'll learn about the untapped potential within every GPU and how GPGPU software can unleash it. You'll see how to use MapReduce to harness massive clusters to solve previously intractible problems, and how, in concert with Stream Processing, big data can be tamed.
With an understanding of the strengths and weaknesses of each of the different models and hardware architectures, you'll be empowered to tackle any problem with confidence.
What You Need:
The example code can be compiled and executed on *nix, OS X, or Windows. Instructions on how to download the supporting build systems are given in each chapter.
This book will show you how to exploit different parallel architectures to improve your code's performance, scalability, and resilience.
Learn about the perils of traditional threads and locks programming and how to overcome them through careful design and by working with the standard library. See how actors enable software running on geographically distributed computers to collaborate, handle failure, and create systems that stay up 24/7/365. Understand why shared mutable state is the enemy of robust concurrent code, and see how functional programming together with technologies such as Software Transactional Memory (STM) and automatic parallelism help you tame it.
You'll learn about the untapped potential within every GPU and how GPGPU software can unleash it. You'll see how to use MapReduce to harness massive clusters to solve previously intractible problems, and how, in concert with Stream Processing, big data can be tamed.
With an understanding of the strengths and weaknesses of each of the different models and hardware architectures, you'll be empowered to tackle any problem with confidence.
What You Need:
The example code can be compiled and executed on *nix, OS X, or Windows. Instructions on how to download the supporting build systems are given in each chapter.
267 pages, Paperback
First published January 22, 2014
102 people are currently reading
1489 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 27 of 27 reviews
January 5, 2016
At work, we selected this book for our development team's book club. So I'm going to be giving my thoughts as well as the thoughts of the rest of my team.
First and foremost, I thought this book was very well written. It's organized well, the "days" are paced well, and the code examples are excellent - easy to follow for the most part (the Wikipedia examples struck me as a bit odd in that they required substantial XML parsing that was not directly included in the book) and did a good job of illustrating the concepts.
While clicking around Goodreads, I clicked the author's name and saw that he actually wrote a book I've read and reviewed previously, "Debug It!" - I kind of eviscerated that book, and I'm happy to report that Paul Butcher's writing has substantially improved since then. I was very impressed with the quality of the writing in the book, the clarity of the prose, and the way in which Paul preemptively answered questions I was having, or told me they'd be addressed soon. It's the sign of a good author who is in touch with his audience when they can anticipate bumps.
One of my complaints, and in fact the complaint of my dev team, was that it simply had too much Clojure. I don't know if this is a fair criticism, but of the 7 concurrency models covered, 3 of them used Clojure (and one of them, the first, only used Java to show how crappy it is to use threads directly, and didn't cover a lot of the concurrency utils in Java).
I did finish this book, but to be completely honest the rest of the team stopped after during Week 4. The book was abandoned and we selected another book for book club. The reason was that people were growing increasingly irritated with the book's overreliance on clojure, and Week 4 was the straw that broke the camel's back. The chapter was on Actors, and rather than doing the obvious thing and doing all the examples with Akka, Elixir was chosen. So this was yet another language to adjust to, and in fact one in which Actors aren't even called Actors (they're Processes in Elixir). This set off my team's "blowhard" alarm and nobody wanted to continue further. It's a shame I didn't get to see their reaction to Butcher's conclusion, where he humblebrags about predicting that parallel programming was going to mainstream two decades ago.
In any case, here's a week by week breakdown, not in order:
Week 1 (Threads) - Great, really good overview, excellent examples of direct threading, and decent use of concurrency utils
Week 3 (Software Transactional Memory) - also great, and since this is clojure's bag it makes sense that this was a clojure chapter
Week 2 (Functional Programming) - this chapter was the first that irritated me and my co-workers. With all the functional programming languages out there, chosing Clojure (an impure functional language, of all things) seemed kind of obnoxious. I have a hunch this was chosen so as to introduce unfamiliar syntax before Week 3, which is fair, but it started to make it feel like this was "a clojure book"
Week 4 (Actors) - Bad. Use Akka, that's what everyone thinks of when they think actors, at least in the non-academic space (and using Clojure rather than Lisp or haskell puts you in a non-academic space).
Week 5 (CSP) - Fine... another Clojure chapter, but I'm honestly not familiar enough with CSP to judge if this was the best tool for the job. I generally find Clojure hard to read so, it's not my personal first choice, but I think it's the right tool for Week 3 because I'm semi-familiar with STM.
Week 6 (GPGPU) - This was a weird chapter to include. Parallelism using GPUs is a bit of a niche, and something that I'd imagine would be covered better in a book devoted to it. It just doesn't seem "general purpose" enough to be in a book about breadth, I found its inclusion odd.
Week 6 (MapReduce) - Fantastic. Really good hands on examples with Hadoop and Storm and EMR. Great stuff, learned a lot here.
So overall, the book is more good than bad, though Butcher makes some frustrating decisions. If you have no interest in Clojure, I think you might want to pass on this book, it's a bit overly reliant on that language and if you dislike reading it I think the book will irritate you. Otherwise it's good and I'd recommend it.
The problem with the "Seven Weeks" series is, every chapter you read it seems like it would be better in its own book. I have to remind myself that these books are about breadth and exposure, not detail. So the fact that there are better books on Hadoop, MapReduce, Threads, STM, and so on out there isn't relevant, because the point is exposure.
That said, I'd be remiss if I didn't suggest Venkat Subramaniam's "Programming Concurrency on the JVM" over this book. Like this book, it too is a breadth/overview book, but rather than covering the second half of this book, it instead focuses on the first few chapters worth of content, namely Threads, STM, and Actors. It goes a bit deeper on each of these subjects by utilizing the room saved by dropping CSP and GPGPU techniques, which I think both didn't really need to be included in this book. I really liked the Lambda Architecture chapter about MapReduce, Hadoop, and so on in this book, but I'm willing to lose it to get an improved version of the chapters on Threads, STM, and Actors. And it has to be mentioned, Venkat's book utilizes the right languages and libraries for those techniques (Java, Clojure, and Scala/Akka respectively).
So this book provides a bit more breadth than Programming Concurrency on the JVM, but it provides it to areas that I think are largely unnecessary. PCotJVM is a bit more focused on the stuff that really matters, and uses better tools for job in my opinion.
First and foremost, I thought this book was very well written. It's organized well, the "days" are paced well, and the code examples are excellent - easy to follow for the most part (the Wikipedia examples struck me as a bit odd in that they required substantial XML parsing that was not directly included in the book) and did a good job of illustrating the concepts.
While clicking around Goodreads, I clicked the author's name and saw that he actually wrote a book I've read and reviewed previously, "Debug It!" - I kind of eviscerated that book, and I'm happy to report that Paul Butcher's writing has substantially improved since then. I was very impressed with the quality of the writing in the book, the clarity of the prose, and the way in which Paul preemptively answered questions I was having, or told me they'd be addressed soon. It's the sign of a good author who is in touch with his audience when they can anticipate bumps.
One of my complaints, and in fact the complaint of my dev team, was that it simply had too much Clojure. I don't know if this is a fair criticism, but of the 7 concurrency models covered, 3 of them used Clojure (and one of them, the first, only used Java to show how crappy it is to use threads directly, and didn't cover a lot of the concurrency utils in Java).
I did finish this book, but to be completely honest the rest of the team stopped after during Week 4. The book was abandoned and we selected another book for book club. The reason was that people were growing increasingly irritated with the book's overreliance on clojure, and Week 4 was the straw that broke the camel's back. The chapter was on Actors, and rather than doing the obvious thing and doing all the examples with Akka, Elixir was chosen. So this was yet another language to adjust to, and in fact one in which Actors aren't even called Actors (they're Processes in Elixir). This set off my team's "blowhard" alarm and nobody wanted to continue further. It's a shame I didn't get to see their reaction to Butcher's conclusion, where he humblebrags about predicting that parallel programming was going to mainstream two decades ago.
In any case, here's a week by week breakdown, not in order:
Week 1 (Threads) - Great, really good overview, excellent examples of direct threading, and decent use of concurrency utils
Week 3 (Software Transactional Memory) - also great, and since this is clojure's bag it makes sense that this was a clojure chapter
Week 2 (Functional Programming) - this chapter was the first that irritated me and my co-workers. With all the functional programming languages out there, chosing Clojure (an impure functional language, of all things) seemed kind of obnoxious. I have a hunch this was chosen so as to introduce unfamiliar syntax before Week 3, which is fair, but it started to make it feel like this was "a clojure book"
Week 4 (Actors) - Bad. Use Akka, that's what everyone thinks of when they think actors, at least in the non-academic space (and using Clojure rather than Lisp or haskell puts you in a non-academic space).
Week 5 (CSP) - Fine... another Clojure chapter, but I'm honestly not familiar enough with CSP to judge if this was the best tool for the job. I generally find Clojure hard to read so, it's not my personal first choice, but I think it's the right tool for Week 3 because I'm semi-familiar with STM.
Week 6 (GPGPU) - This was a weird chapter to include. Parallelism using GPUs is a bit of a niche, and something that I'd imagine would be covered better in a book devoted to it. It just doesn't seem "general purpose" enough to be in a book about breadth, I found its inclusion odd.
Week 6 (MapReduce) - Fantastic. Really good hands on examples with Hadoop and Storm and EMR. Great stuff, learned a lot here.
So overall, the book is more good than bad, though Butcher makes some frustrating decisions. If you have no interest in Clojure, I think you might want to pass on this book, it's a bit overly reliant on that language and if you dislike reading it I think the book will irritate you. Otherwise it's good and I'd recommend it.
The problem with the "Seven Weeks" series is, every chapter you read it seems like it would be better in its own book. I have to remind myself that these books are about breadth and exposure, not detail. So the fact that there are better books on Hadoop, MapReduce, Threads, STM, and so on out there isn't relevant, because the point is exposure.
That said, I'd be remiss if I didn't suggest Venkat Subramaniam's "Programming Concurrency on the JVM" over this book. Like this book, it too is a breadth/overview book, but rather than covering the second half of this book, it instead focuses on the first few chapters worth of content, namely Threads, STM, and Actors. It goes a bit deeper on each of these subjects by utilizing the room saved by dropping CSP and GPGPU techniques, which I think both didn't really need to be included in this book. I really liked the Lambda Architecture chapter about MapReduce, Hadoop, and so on in this book, but I'm willing to lose it to get an improved version of the chapters on Threads, STM, and Actors. And it has to be mentioned, Venkat's book utilizes the right languages and libraries for those techniques (Java, Clojure, and Scala/Akka respectively).
So this book provides a bit more breadth than Programming Concurrency on the JVM, but it provides it to areas that I think are largely unnecessary. PCotJVM is a bit more focused on the stuff that really matters, and uses better tools for job in my opinion.
July 26, 2014
Very enjoyable as long as you accept author's idea for the book:
1.) This is NOT a book about theoretical differences between different concurrency models. It just describes the practical aspects, but there's barely any comparison.
2.) This book does NOT dive into details of any of the 7 described concurrency models. Idea is to present the basics of all 7, very different models.
3.) Author is not afraid of using truly 'exotic' languages (Elixir) & frameworks (core.async) - spread of languages & technologies is impressive.
What did I enjoy most? High number of examples & variety of technologies presented. I have a limited experience with Clojure & no experience with Elixir, so reading about them was a great fun :D.
What should be changed / improved / fixed?
Some examples should really, really get pictures. I've worked with Actor model before, so I'm not such a newbie, but actor-related example was a bit illegible.
Anyway, it's a good book if you're interested in concurrency & you're not afraid of its polyglot approach.
1.) This is NOT a book about theoretical differences between different concurrency models. It just describes the practical aspects, but there's barely any comparison.
2.) This book does NOT dive into details of any of the 7 described concurrency models. Idea is to present the basics of all 7, very different models.
3.) Author is not afraid of using truly 'exotic' languages (Elixir) & frameworks (core.async) - spread of languages & technologies is impressive.
What did I enjoy most? High number of examples & variety of technologies presented. I have a limited experience with Clojure & no experience with Elixir, so reading about them was a great fun :D.
What should be changed / improved / fixed?
Some examples should really, really get pictures. I've worked with Actor model before, so I'm not such a newbie, but actor-related example was a bit illegible.
Anyway, it's a good book if you're interested in concurrency & you're not afraid of its polyglot approach.
April 28, 2015
Much like the the original
Seven Languages in Seven Weeks
by Bruce Tate, this is a great idea that is really hard to pull off, and more than a little bit challenging to take in as a reader. Trying to tackle this subject is very ambitious, particularly because the promise of this particular series is that the authors are going to take you beyond pure theory and demonstrate the practical applications of each of the seven highlighted paradigms (even if those "practical applications" are somewhat contrived and/or trivial). But that's also what's so goddamn enticing here: reading a bunch of academic baloney about the Actor model is all well and good but sometimes you need that little nudge that will carry you right into the loving arms of a Real World Example™. And it's those Real World Examples that are worth the price of admission, getting your hands dirty and really seeing why (and not just how) to apply a given concurrency/parallelism paradigm to a particular class of problem.
But this is also where things can be a bit challenging for (some) readers. If you are unable or unwilling to fully engage with the text -- to really dig into those examples and follow through on each of the FIND and DO follow-up sections... Well, it winds up just feeling like more of the same academic and/or in-the-abstract discussions. If you've read any of the other 7-in-7 series books, you're likely familiar with that point and are nodding vigorously there. But what makes this book doubly so is that not only are you learning the concurrency/parallelism paradigms, but you may also be having to learn "just enough" of the languages that go along with it.
Unfortunately for me, this one hit me in the sweet spot where my interest was very high, but my patience was at an all time low -- a double-dose of frustration and disappointment. Which is not to say that I didn't get anything out of this book -- it's certainly possible to take in quite a bit of academic and/or in-the-abstract information about the seven paradigms even without digging deep into the exercise. But... you'll miss out if you can't or don't. (I missed out.)
But this is also where things can be a bit challenging for (some) readers. If you are unable or unwilling to fully engage with the text -- to really dig into those examples and follow through on each of the FIND and DO follow-up sections... Well, it winds up just feeling like more of the same academic and/or in-the-abstract discussions. If you've read any of the other 7-in-7 series books, you're likely familiar with that point and are nodding vigorously there. But what makes this book doubly so is that not only are you learning the concurrency/parallelism paradigms, but you may also be having to learn "just enough" of the languages that go along with it.
Unfortunately for me, this one hit me in the sweet spot where my interest was very high, but my patience was at an all time low -- a double-dose of frustration and disappointment. Which is not to say that I didn't get anything out of this book -- it's certainly possible to take in quite a bit of academic and/or in-the-abstract information about the seven paradigms even without digging deep into the exercise. But... you'll miss out if you can't or don't. (I missed out.)
April 19, 2015
Tuto knihu mohu doporučit všem, co to myslí s vývojem aspoň trochu vázně. A je jedno jestli dělají front-end v JavaScriptu, back-end v PHP nebo nějakou enterprise aplikaci. Každý si tam najde něco, co mu pomůže podívat se na problematiku efektivního psaní aplikací z trochu jiného úhlu.
Je zde srozumitelně popsán rozdíl mezi konkurencí, paralelismem a asynchronicitou. Jsou zde popsány různé přístupy k řešení konkurenčních přístupů s přihlédnutím k tomu, na jakou množinu problémů jsou vhodněšní či na jaké zcela nevhodné.
Ukázky v knize jsou v různých jazycích - ať už v provařené Javě nebo Céčku, tak i v moderních jazycích jako je Clojure nebo Elixir. Pokud tyto jazyky vůbec neznáte, nebojte se. Kniha vás s Clojure i Elixirem seznámí tak, abyste ukázky nejen pochopili, ale abyste byli schopní napsat v nich netriviální programy. Nečekejte důvěrné seznámení, ale úvod do programování v Clojure, ve které je značná část ukázek, v typických scénářích jejího užití.
Já osobně jsem se dozvěděl mnoho a to se této problematice věnuji již drahnou dobu. Dle mého názoru by tato kniha neměla chybět v žádné knihovně.
Je zde srozumitelně popsán rozdíl mezi konkurencí, paralelismem a asynchronicitou. Jsou zde popsány různé přístupy k řešení konkurenčních přístupů s přihlédnutím k tomu, na jakou množinu problémů jsou vhodněšní či na jaké zcela nevhodné.
Ukázky v knize jsou v různých jazycích - ať už v provařené Javě nebo Céčku, tak i v moderních jazycích jako je Clojure nebo Elixir. Pokud tyto jazyky vůbec neznáte, nebojte se. Kniha vás s Clojure i Elixirem seznámí tak, abyste ukázky nejen pochopili, ale abyste byli schopní napsat v nich netriviální programy. Nečekejte důvěrné seznámení, ale úvod do programování v Clojure, ve které je značná část ukázek, v typických scénářích jejího užití.
Já osobně jsem se dozvěděl mnoho a to se této problematice věnuji již drahnou dobu. Dle mého názoru by tato kniha neměla chybět v žádné knihovně.
August 4, 2014
Než přejdu k dílčím výtkám, chci zdůraznit, že se jedná o velmi dobrou knihu, která je rychlým úvodem do moderního, i když v některých kapitolách možná jen módního :) psaní konkurenčního/paralelního kódu.
Obával jsem se, že kniha bude napsána velmi povrchně, protože množství v knize použitých jazyků (Java, Clojure, Elixir, C ...) i ohraničení předpokládané doby čtení (? seven weeks ?) v titulu knihy vzbuzuje podezření, že autor bude přelétat z tématu na téma, z jednoho řešení konkurenčního kódu na druhé a povrchnost výkladu se bude snažit maskovat i rozsah knihy uměle nastavovat výkladem syntaktických konstrukcí méně známých jazyků. Tak tomu ale není a podle mě Paul Butcher velmi dobře odhadl, kolik syntaktických konstrukcí je třeba osvětlit, aby čtenář netápal a současně aby se pod nánosem formalizované jazykové hlušiny neztratilo hlavní téma každé kapitoly.
Teď k těm výtkám:
1) Kapitola o threadech a kritických sekcích (zámcích) působí tak, že autor ve finální verzi knihy vyškrtal některé pasáže, a proto jsou v knize zavádějící nebo neúplné informace.
Jestliže už má autor potřebu začít mluvit o paměťovém modelu a o možném "reorderingu" instrukcí, čekal bych, že kromě vágního popisu problému s "reorderingem" a "double check" vzorem v Javě zazní i něco o "acquire", "release" a "relax" sémantice.
Už jen proto, že v další části knihy (GPGPU) se autor o "relax" sémantice v souvislosti se synchronizační primitivou typu "barrier" zmiňuje.
To samé ve stejné kapitole platí pro klíčové slovo volatile v Javě - nezazní nic o volatilním čtení/volatilním zápisu, implicitní acquire/release sémantice a ani není vysvětleno, jaká je režie klíčového slova volatile.
U deadlocků by měly zaznít všechny Coffmanovy podmínky pro deadlock, aby bylo zřejmé, jak se dá deadlockům předcházet.
Lepší popis výše zmíněných témat je ve špičkové knize Concurrent programming in Windows.
(principy v ní popsané navzdory názvu knihy platí nejen ve Windows)
https://www.goodreads.com/review/show...
O paměťovém modelu v C++ 11 pojednává skvěle A. Williams v knize
C++ Concurrency in Action
https://www.goodreads.com/book/show/6...
2) V kapitole u aktorů bych rád viděl popsány důsledky synchronního/asynchronního čekání v jednom aktorovi na odpověď jiného aktora. To je podle mě jeden z největších problémů aktor modelu, protože je velmi snadné spadnout do pasti, která se dá ve zkratce popsat takto:
a) Při synchronním čekání na odpověď jiného aktora nezpracováváte žádné další zprávy z "mailboxu". Důsledky jsou zřejmé - aktorovi se plní "mailbox" a nikdy si nemůžete být jisti, kdy vám jiný aktor odpoví.
b) Při asynchronním čekání na výsledek volání jiného aktora máte aktora v nekonzinstentním stavu, protože jste ještě zcela nezpracovali původní zprávu. Jestliže se rozhodnete před přijetím odpovědi zpracovat další zprávu, vystavujete se riziku, že aktor už není aktorem s neproblematickým a deterministickým vnitřním stavem při zahájení i ukončení zpracování každé zprávy. Aktor pak v tomto scénáři nedodržuje striktně sekvenční a exkluzivní zpracování zpráv, které je podle mě jedním z hlavních definičních znaků "pravého" aktora.
Při asynchronním zpracování odpovědi nemusí být zpracování zpráv sekvenční. Sice stále platí, že je v jednom okamžiku zpracovávána v jednom aktorovi maximálně jedna zpráva, ale samostatné fáze zpracování různých zpráv se mohou při čekání na odpověď prolínat. Jestliže se rozhodnete, že žádnou další zprávu při asychronním čekání na odpověď nezpracujete, máte stejné problémy jako při synchronním čekání na odpověď, které jsem popsal v bodě a.
Zdůraznil bych, že skutečný aktor nikdy při zpracování jedné zprávy nečeká na odpověď od jiného aktora, protože to je alespoň podle mých zkušeností v aplikacích jediný udržitelný model.
Komunikaci mezi aktory je třeba navrhnout tak, abyste si odpověď od jiného aktora při zpracování zprávy nevynucovali. Zprávy mezi aktory by měly být odesílány stylem "Fire (message) & forget".
Autor pravděpodobně na podobné problémy upozorňuje jen obecně v závěru kapitoly, kde v popisu slabých a silných stránek aktor modelu popisuje, že i aktor model je náchylný k deadlockům a že další problémy v aplikaci může přinést přeplnění "mailboxu" aktora.
3) Poslední dvě kapitoly o GPGPU a "lambda architektuře" (Hadoop, Storm) jsou tématicky hodně odlišné od předchozích kapitol a příklady v nich mi přijdou nedostačující. Raději bych místo těchto kapitol viděl v knize úvod do RX Frameworku, který se podle autorova závěrečného slova do knihy už bohužel nevešel.
Obával jsem se, že kniha bude napsána velmi povrchně, protože množství v knize použitých jazyků (Java, Clojure, Elixir, C ...) i ohraničení předpokládané doby čtení (? seven weeks ?) v titulu knihy vzbuzuje podezření, že autor bude přelétat z tématu na téma, z jednoho řešení konkurenčního kódu na druhé a povrchnost výkladu se bude snažit maskovat i rozsah knihy uměle nastavovat výkladem syntaktických konstrukcí méně známých jazyků. Tak tomu ale není a podle mě Paul Butcher velmi dobře odhadl, kolik syntaktických konstrukcí je třeba osvětlit, aby čtenář netápal a současně aby se pod nánosem formalizované jazykové hlušiny neztratilo hlavní téma každé kapitoly.
Teď k těm výtkám:
1) Kapitola o threadech a kritických sekcích (zámcích) působí tak, že autor ve finální verzi knihy vyškrtal některé pasáže, a proto jsou v knize zavádějící nebo neúplné informace.
Jestliže už má autor potřebu začít mluvit o paměťovém modelu a o možném "reorderingu" instrukcí, čekal bych, že kromě vágního popisu problému s "reorderingem" a "double check" vzorem v Javě zazní i něco o "acquire", "release" a "relax" sémantice.
Už jen proto, že v další části knihy (GPGPU) se autor o "relax" sémantice v souvislosti se synchronizační primitivou typu "barrier" zmiňuje.
To samé ve stejné kapitole platí pro klíčové slovo volatile v Javě - nezazní nic o volatilním čtení/volatilním zápisu, implicitní acquire/release sémantice a ani není vysvětleno, jaká je režie klíčového slova volatile.
U deadlocků by měly zaznít všechny Coffmanovy podmínky pro deadlock, aby bylo zřejmé, jak se dá deadlockům předcházet.
Lepší popis výše zmíněných témat je ve špičkové knize Concurrent programming in Windows.
(principy v ní popsané navzdory názvu knihy platí nejen ve Windows)
https://www.goodreads.com/review/show...
O paměťovém modelu v C++ 11 pojednává skvěle A. Williams v knize
C++ Concurrency in Action
https://www.goodreads.com/book/show/6...
2) V kapitole u aktorů bych rád viděl popsány důsledky synchronního/asynchronního čekání v jednom aktorovi na odpověď jiného aktora. To je podle mě jeden z největších problémů aktor modelu, protože je velmi snadné spadnout do pasti, která se dá ve zkratce popsat takto:
a) Při synchronním čekání na odpověď jiného aktora nezpracováváte žádné další zprávy z "mailboxu". Důsledky jsou zřejmé - aktorovi se plní "mailbox" a nikdy si nemůžete být jisti, kdy vám jiný aktor odpoví.
b) Při asynchronním čekání na výsledek volání jiného aktora máte aktora v nekonzinstentním stavu, protože jste ještě zcela nezpracovali původní zprávu. Jestliže se rozhodnete před přijetím odpovědi zpracovat další zprávu, vystavujete se riziku, že aktor už není aktorem s neproblematickým a deterministickým vnitřním stavem při zahájení i ukončení zpracování každé zprávy. Aktor pak v tomto scénáři nedodržuje striktně sekvenční a exkluzivní zpracování zpráv, které je podle mě jedním z hlavních definičních znaků "pravého" aktora.
Při asynchronním zpracování odpovědi nemusí být zpracování zpráv sekvenční. Sice stále platí, že je v jednom okamžiku zpracovávána v jednom aktorovi maximálně jedna zpráva, ale samostatné fáze zpracování různých zpráv se mohou při čekání na odpověď prolínat. Jestliže se rozhodnete, že žádnou další zprávu při asychronním čekání na odpověď nezpracujete, máte stejné problémy jako při synchronním čekání na odpověď, které jsem popsal v bodě a.
Zdůraznil bych, že skutečný aktor nikdy při zpracování jedné zprávy nečeká na odpověď od jiného aktora, protože to je alespoň podle mých zkušeností v aplikacích jediný udržitelný model.
Komunikaci mezi aktory je třeba navrhnout tak, abyste si odpověď od jiného aktora při zpracování zprávy nevynucovali. Zprávy mezi aktory by měly být odesílány stylem "Fire (message) & forget".
Autor pravděpodobně na podobné problémy upozorňuje jen obecně v závěru kapitoly, kde v popisu slabých a silných stránek aktor modelu popisuje, že i aktor model je náchylný k deadlockům a že další problémy v aplikaci může přinést přeplnění "mailboxu" aktora.
3) Poslední dvě kapitoly o GPGPU a "lambda architektuře" (Hadoop, Storm) jsou tématicky hodně odlišné od předchozích kapitol a příklady v nich mi přijdou nedostačující. Raději bych místo těchto kapitol viděl v knize úvod do RX Frameworku, který se podle autorova závěrečného slova do knihy už bohužel nevešel.
March 21, 2016
Very well-structured and surprisingly digestible, given the subject matter. Each chapter is broken up into 3 sections, the idea being you can cover one section a day over a long weekend. There are checkpoints and summaries of what you just covered, which is helpful. There's some weird stuff that you probably wouldn't use for real until you really need them, so if you're not at that point yet (like me), the intention of reading about these topics is to become more familiar with the general terminology and overview of ideas.
If you're a Rubyist and new to the topic of concurrency, I'd probably still recommend Working with Ruby Threads and Rob Pike's talk on Concurrency and Parallelism first, but this is a cool way to branch out from there and explore other techniques and languages.
If you're a Rubyist and new to the topic of concurrency, I'd probably still recommend Working with Ruby Threads and Rob Pike's talk on Concurrency and Parallelism first, but this is a cool way to branch out from there and explore other techniques and languages.
May 23, 2016
The value of this book is not so much in a straight reading of it, but rather in all of the additional study and reading that it inspires you to do. So if you just read it from A to Z you will get some idea about different concurrency models and expand your horizons in a fairly interesting way (honestly I didn't foresee a Lambda Architecture being a concurrency model, though it definitely is), but I think at the end your brain will be somewhat disorganized, because chapters themselves are running through the material way too fast and most of the time way too shallow. But if you do all of the exercises... You will probably end up learning a basics of couple of interesting programming languages like Go and Clojure, listen to the genius presentations of Rich Hickey and learn how to run Hadoop on EMR cluster which is quite an amount of professional growth.
February 26, 2014
In current state (beta) it's more between 3 & 4 stars...
The book covers popular concurrency models, starting with usual threads/locks, and then to transactional memory, CSP, etc.
The choice of languages is interesting - Clojure is used to demonstrate "functional" concurrency (parallel map, reducers) & state/identity separation (transactional memory, agents, atoms), Elixir is used to demonstrate Actor model. It was surprising for me to see that the Clojure's core.async is used to demonstrate CSP, instead of more popular Go...
The book requires some knowledge of Clojure (Seven Languages in Seven Weeks could be a good choice), but anyway, it provides pretty good overview of different models and would be useful if you want to look to something "non-standard"...
The book covers popular concurrency models, starting with usual threads/locks, and then to transactional memory, CSP, etc.
The choice of languages is interesting - Clojure is used to demonstrate "functional" concurrency (parallel map, reducers) & state/identity separation (transactional memory, agents, atoms), Elixir is used to demonstrate Actor model. It was surprising for me to see that the Clojure's core.async is used to demonstrate CSP, instead of more popular Go...
The book requires some knowledge of Clojure (Seven Languages in Seven Weeks could be a good choice), but anyway, it provides pretty good overview of different models and would be useful if you want to look to something "non-standard"...
August 1, 2014
Great book. A must read for contemporary software engineers.
Although the chapter on GPGPU was somewhat alien to the rest of the book and the chapter on big data came somewhat short (probably because of the relative complexity of the topic).
Although the chapter on GPGPU was somewhat alien to the rest of the book and the chapter on big data came somewhat short (probably because of the relative complexity of the topic).
February 1, 2015
Good read. Was interesting to see how concurrency challenges are solved using different languages. Too much Clojure as for me (3 chapters of 8). Very nice chapter about Elixir (actor-based concurrency).
January 28, 2016
well, the book is wide-covering, interesting (almost like science-fiction) and with a lot of code samples, the only disadvantage - several different programming languages are used for these samples, sometimes quite exotic
February 12, 2015
Pretty nice and at any rate very useful book. Good to see how to deal with similar problems from different points of view. Whole range of technologies is presented including - but not limited to - Clojure's channels and Go macro, Elixir Actors, GPU programming with OpenCL, Hadoop and many more.
Some critique points - C examples feel sometimes strange. The whole last "Lambda architecture" chapter is the Big Data chapter. The Lambda architecture seems to stand very close to CQRS with Event Sourcing. Not sure why the latter not even mentioned, would be good to see two technologies in comparison.
Some critique points - C examples feel sometimes strange. The whole last "Lambda architecture" chapter is the Big Data chapter. The Lambda architecture seems to stand very close to CQRS with Event Sourcing. Not sure why the latter not even mentioned, would be good to see two technologies in comparison.
October 18, 2015
Interesting overview of different concurrency models and techniques. Mostly focused on functional programming. But very often it's too detailed for general overview and too superficial for those who really want details.
July 24, 2015
nice walk through of interesting concurrency modelling ideas prevalent across various languages.
November 3, 2021
Эта книга хороша своими ссылками. Во-первых, я наконец-то удосужился прочесть статью по джаве, объясняющую, почему Double-Checked Locking не работает: инлайнинг конструкторов плюс реордеринг инструкций могут подарить нам полуинициализированный синглтон. Во-вторых, узнал, почему реализацию STM в .NET бросили в 2010. По мнению главного исследователя msft, в реальном мире мы чаще имеем дело с нетранзакционными эффектами, вроде взаимодействий с внешними сервисами, UI, файлами и логами(интересно, как к этому заявлению относятся господа функциональные программисты).
Понравилась глава про акторы на примере эликсира, узнал оттуда термин Error Kernel. Правда, оказалось, я еще что-то помню после курсовика по эрлангу, и let it crash и OTP не откровение. Главы про OpenCL и MapReduce неплохие, как и про блокировки на примере java.
Что не понравилось: три главы про clojure, причем одна из них про CSP, и почему-то go автор не взял. Это, конечно, иррациональная претензия, но недовольство овердозом кложи тут почти в каждой рецензии.
Если оценивать бесстрастно, книга хорошая и автор точно понимает, о чем пишет, но на четвертую звезду рука не поднялась.
Понравилась глава про акторы на примере эликсира, узнал оттуда термин Error Kernel. Правда, оказалось, я еще что-то помню после курсовика по эрлангу, и let it crash и OTP не откровение. Главы про OpenCL и MapReduce неплохие, как и про блокировки на примере java.
Что не понравилось: три главы про clojure, причем одна из них про CSP, и почему-то go автор не взял. Это, конечно, иррациональная претензия, но недовольство овердозом кложи тут почти в каждой рецензии.
Если оценивать бесстрастно, книга хорошая и автор точно понимает, о чем пишет, но на четвертую звезду рука не поднялась.
October 2, 2017
I would say it is good for entry to mediate level of concurrency programming. Will have better understanding if you already know Java&Clojure&Elixir&OpenCL.
The structure of the book is clear, from original concurrency problems to popular (well, a little out of date now) MapReduce. In most of case, it uses "conclusion then samples" pattern to explain the idea. It works well to some people like me. The problem is those samples are not quite practical, especially the environment setup is not handy and it is definitely not the scope of this book. So if you plan to execute those samples, you need to plan more time in practice.
Overall, it is a good book to understand a perspective of concurrency problem and solution. I would recommend this book.
The structure of the book is clear, from original concurrency problems to popular (well, a little out of date now) MapReduce. In most of case, it uses "conclusion then samples" pattern to explain the idea. It works well to some people like me. The problem is those samples are not quite practical, especially the environment setup is not handy and it is definitely not the scope of this book. So if you plan to execute those samples, you need to plan more time in practice.
Overall, it is a good book to understand a perspective of concurrency problem and solution. I would recommend this book.
June 9, 2021
Nice approach to different models and architectures. I just didn't like the data parallelism part. The concurrency model is basically the same as other previous approaches, only applied to a specific tool.
June 7, 2017
Very good book, a less cloujure would make it more readable for me. I am going to get back to this book *after* I became more fluent in Clojure.
November 25, 2017
Interesting survey of parallel & concurrent computing techniques. Mostly Clojure.
July 9, 2020
Not very help for concurrency.
January 20, 2022
- A good overview of concurrent and parallel programming
- But based on languages like Clojure and Erlang makes it hard to read
- But based on languages like Clojure and Erlang makes it hard to read
May 29, 2016
Inizia molto bene, spiegando la programmazione multithread, ma già dal primo capitolo scade nella spiegazione degli internal di alcune strutture dati di Java, invece di concentrarsi sul rendere la spiegazione multilinguaggio.
Dal secondo capitolo inizia ad usare linguaggi (clojure, elixir) e framework/librerie (opencl) sconosciuti alla maggior parte degli sviluppatori con una minima e inutile introduzione, visto che la sintassi è completamente diversa da qualsiasi linguaggio non funzionale, rendendo ancora più incomprensibili le spiegazioni che dà (o meglio... non dà).
Forse per chi conosce già bene tutti i linguaggi usati può essere utile a migliorarne l'uso, ma per tutti gli altri è assolutamente inutile.
Dal secondo capitolo inizia ad usare linguaggi (clojure, elixir) e framework/librerie (opencl) sconosciuti alla maggior parte degli sviluppatori con una minima e inutile introduzione, visto che la sintassi è completamente diversa da qualsiasi linguaggio non funzionale, rendendo ancora più incomprensibili le spiegazioni che dà (o meglio... non dà).
Forse per chi conosce già bene tutti i linguaggi usati può essere utile a migliorarne l'uso, ma per tutti gli altri è assolutamente inutile.
July 14, 2016
Overall a readable and useful book. As it's with PragPub publications, it's a bit too skewed towards examples and JVM based solutions (as for my taste), i.e. I don't particularly appreciated discussion on Clojure's innerworkings, Rx or Elm could easily step in for ClojureScript etc. Nonetheless, good book if you think you know a bit already, want to learn more and aren't ready to dive deep into particular domain (Akka, GPGPU, Spark, etc) or just want to widen your horizons.
April 3, 2021
Great to see these different ideas in one place. It was especially fun to jump into Clojure and see its unique insights about persistent data structures, channels, and immutable databases. However, I think I'll probably try to incorporate these in Java programming rather than making the switch to Clojure. It seems like many of the issues Clojure tries to solve have been solved with microservice architecture and cloud-native development. Looking forward to playing around with Elixir.
September 27, 2015
Like the other books in the Seven in Seven series, it just gets the reader familiarized with the concepts out there. One cannot read this book and can understand the concept of neither concurrency nor parallelism.
May 3, 2016
Читать стоит для расширения кругозора. Перевод на русский хороший, но местами хромает. Если есть возможность читать на англ., читайте на англ.
October 31, 2014
"everything is possible with Clojure"
Displaying 1 - 27 of 27 reviews