This release of the parallel programming book features a new data-ownership chapter, the start of a new validation chapter, and lots of fixes, primarily from Elie De Brauwer.
I expect to put out the next release in December. I will continue on validation, and hopefully get a few other things accomplished.
As always, git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/perfbook.git will be updated in real time.
paulmckrcu 
Epub format?
Any progress with the plans to use Pandoc to create a .epub or .mobi variant of the book? I did not manage to convert the pdf into epub format with Pandoc or Calibre, and I am having difficulties in building even the pdf version on Fedora 15 (broken a2ping).
Re: Epub format?
Sad to say, no progress. 😦
But I do have a (very rough) HTML version — can that be converted to epub format? That would allow you to get the benefit of my a2ping.
Also, did you file a Fedora bug on a2ping? If not, could you please do so?
Why are academic papers double-column?
The reason is that double-column format gets more content per page. One way to see this is to consider that the a paragraph in single-column format will waste on average half a line, while a paragraph in double-column format will waste on average one quarter of a line (half of a column).
Of course, this should matter less as paper becomes less prevalent, and is why this book is available in both single-column and double-column formats. (That said, the single-column format does need a bit of help from someone with better Latex skills than I have.)
Re: Epub format?
Thank you for filing the bug!
And yes, the HTML version is still experimental. It is a lot better than it was initially, but it needs more help. Most of the work to this point has been preprocessing the document so that latex2html will deal (more or less) with it. I am toying with the idea of writing a special-purpose script that takes perfbook_flat.tex and making one big .html out of it, but not sure that this would be all that great an approach.
Other options I should consider?
This looks horribly familiar
After thinking about the article for some two days or so I start to get the feeling that a “transaction” as seen here is very close to the concept of “monad” from functional programming, as used in Haskell specifically, where any sequences of operations in a sequential programming sense are encapsulated in a Monad to hide side effects from the purely “functional world” inside a functional program.
What transactional memory achieves is encapsulation of the side effect of interacting with other processes, which can be likened to I/O really, as passed a token between these processes would be equivalent to taking a lock. So we could as well call it “monadic memory” – what we want to hide is the interaction with something outside of our smooth program flow. Two communicating Haskell processes could conveniently encapsulate their IPC as a monadic operation implemented by a transaction through a TM.
That is hardly a coincidence: when some research projects in the 70ies and 80ies tried to deal with massive parallelism they often came up with functional programming and distributed reduction of the parse-tree bottom-up as the way to go about things. Such was the case with e.g. the japanese fifth generation computer. Those would use Prolog to achieve a functional approach to the problem. (I’m told the Connection Machine did something similar.)
One *could* argue that by actively avoiding to redefine our problems in domain-specific languages (functional, data flow etc) we have come to the point where features of these languages come creeping in from the bottom layer of the architecture. On the other hand one could also argue that this way only the features that we really need from these languages have crystallized from the hardware side of things.
Anyway, thanks for an extremely thought-provoking article that really made me think about things!
Linus Walleij
wow this book is perfect, exactly what i needed! THX