[Python-Dev] Pythonic concurrency

[Bruce Eckel]

> I spent a few weekends studying that paper earlier this year in order to
> see if anything could be stolen for Python; my general impression was "not
> easily" at the least.  One notable feature of the presented concept was
> that when code would otherwise block, they *rolled it back* to the last
> nonblocking execution point.  In a sense, they ran the code backwards,
> albeit by undoing its effects.  They then suspend execution until there's a
> change to at least one of the variables read during the forward execution,
> to avoid repeated retries.

I haven't spent the weekends on the paper yet (but it looks like that
is what it would take), but I had the impression that they were
talking about the lock-free techniques such as the ones used in Java
5. Basically, you start a write operation "in the background" without
locking the data structure, so reads can continue while the
calculation is taking place but before the result is committed. When
the result is ready, an atomic "test and write" operation is used to
determine whether any other task has modified the value in the
meantime, and if not to commit the new value. If another task did
modify the value, then the calculation begins anew.

That was my take, but I haven't studied everything about STM yet, so
I'm probably missing something.

The one thing about this paper is that it seems to be an orthogonal
perspective to anything about concurrency that *I* have seen before.

> Oddly enough, this paper actually demonstrates a situation where having
> static type checking is in fact a solution to a non-trivial problem!  It
> uses static type checking of monads to ensure that you can't touch 
> untransacted things inside a transaction.

Yes, because of some of my diatribes against static checking people
get the impression that I think it's just a bad thing. However, I'm
really trying to get across the idea that "static type checking as the
solution to all problems is a bad idea," and that the cost is often
much greater than the benefit. But if there really is a clear payoff
then I'm certainly not averse to it. In general, I really *do* like to
be told when something has gone wrong -- I think there's a huge
benefit in that. But if I can learn about it at runtime rather than
compile time, then that is often a reasonable solution.

So with concurrency, I would like to know when I do something wrong,
but if I am told at runtime that's OK with me as long as I'm told.

Bruce Eckel    http://www.BruceEckel.com   mailto:BruceEckel-Python3234 at mailblocks.com
Contains electronic books: "Thinking in Java 3e" & "Thinking in C++ 2e"
Web log: http://www.artima.com/weblogs/index.jsp?blogger=beckel
Subscribe to my newsletter:
http://www.mindview.net/Newsletter
My schedule can be found at:
http://www.mindview.net/Calendar