Beautiful concurrency[edit]

I have written a chapter for a book called "Beautiful code", edited by Greg Wilson. The chapter is a tutorial about Software Transactional Memory in Haskell. The book is aimed at a general audience of programmers, not Haskell geeks, so I have tried to explain everything necessary as I go along.

You can find the paper itself, and the code download here. This Wiki talk-page is a place to contribute any post-publication thoughts or observations about the paper, if you wish.

Simonpj 14:26, 22 December 2006 (UTC) To add a note, begin with four tilde signs ~~~~; the Wiki will fill in your user name and date.

Croach 17:10, 21 February 2007 (UTC)I just wanted to mention that it appears there is a small typo in the example code on page 2 of the paper. In the code you have a synchronized method called "withdraw" which you use again in the non-synchronized "deposit" method, only here you call the "withdraw" method "withdrawn". By the way, absolutely wonderful paper. I've been trying to learn everything I can about both Haskell and STM in the past few months and not only did this paper greatly increase my knowledge of STM, but it also helped increase my understanding of the basics of Haskell, which I already assumed I had a good grasp on. So, thank you for this work, it was an absolute joy to read.

CloudiDust 16:24, 25 February 2007 (UTC) Thanks very much for this wonderful paper! I'm gaining a lot from it now as both a newbie to Haskell and one to concurrency. Here are the typos I have found:

A. There is no "Int" but "int" in java. (I suppose they are java codes. :)

B. In the code at the beginning of Page 3, there seems to be a semicolon missing after "to.unlock()".

C. In the Footnote 2 in Page 5, the sentence "That’s because Haskell supports currying, which can you can ..." seems to duplicate a "can", and there seems to be a right parenthesis missing after "e.g. [13]".

I'm now busy translating this paper into Chinese, and will feedback as often as I can. I wonder whether I can put my translation on the net and if so which license could I use? Many thanks again!

TuukkaH 22:07, 23 June 2007 (UTC) What can we say about the relation to message passing: Solving the Santa Claus Problem in Erlang?

ChrisKuklewicz 14:08, 25 June 2007 (UTC) In response to TuukkaH, I have posted code at Santa which is just a short adaptation of the Erlang to Haskell using just Chan and TChan (to get orElse).

TuukkaH 14:33, 5 July 2007 (UTC) Thanks ChrisKuklewicz! I interpret that as Haskell supporting message passing better than Erlang, and it actually being a subconcept in STM too.

Alisezgin 12:59, 31 December 2007 (UTC) it was a good read. i will have to look into a more detailed exposition pretty soon. but one quick question:

from what i understand, an atomic block can only have side effects on stm variables. what if i want to have a block of io instructions (like launchmissiles) that need to be executed with no intervening instructions/threads, that is, atomically? this is of course assuming that rolling back will not be needed for this specific block. is this something that is fundamentally disallowed because it is poor programming practice? admittedly, i am no concurrent programmer so i am not familiar with what might come up while designing a concurrent system.

Cjs 08:12, 6 January 2009 (UTC) For I/O, you need to use locks. STM isn't a pancea. The reason the whole rollback thing works so well for STM in Haskell (it's a major problem in most non-Haskell STM implementations) is because the code run in the STM monad is pure (i.e., can't do I/O).