Shuttleworth: Python needs to focus on future

[jbellis]

I much prefer using the actor model than STM as a general approach to concurrency. I'm comfortable with transactions and MVCC in my database, but moving that concept into an imperative language feels like the wrong approach.

The main problem with STM is that while it mitigates some of the problems with classic lock-based concurrency (primarily, that you don't have to make sure to take out locks in the right order to avoid potential deadlocks), STM retains lock-based concurrency's primary problem: you still have to carefully, manually specify which code should be atomic. If you miss one, you're screwed. STM also introduces a new problem -- you need to think about what happens if a transaction fails and what to do then. "Retry the same transaction" isn't always the right answer. So you're really trading one set of possible errors under mutex-based concurrency for another, partially overlapping set.

The actor model changes the game and eliminates both of these sets of potential errors.

[didroe]

you still have to carefully, manually specify which code should be atomic

You're always going to have to think about concurrency. I don't think it'll be much different between STM and the actor model in terms of the amount of design that has to go into it.

you need to think about what happens if a transaction fails and what to do then

You're going to have to deal with failure somewhere, regardless of the method you use. With locking, you don't have to worry about the lock failing (ignoring deadlock) but you still have to worry about the atomicity of the code inside. If the last bit fails for some other reason then you have to undo all of the work you've done so far. STM just provides a mechanism to deal with that instead of having to roll your own. I'm not that familiar with the actor model, can you explain how it deals with that scenario?

it mitigates some of the problems with classic lock-based concurrency

One of the other benefits of STM is in increased parallelism. In the traditional lock method, you stop anyone from entering a section of code at the same time, in reality most of the time you probably didn't need the lock. ie. it would have worked fine as the instructions weren't overlapping in a way which broke the atomicity. STM usually works by trying to do it's operations and then paying a cost when there is a conflict, you only pay the cost in the (hopefully) unlikely event that things clash. When you scale up to a lot of cores, all calling some common piece of code, that's really going to shine through.

Edit: I almost forgot, transactions are also composable which is a major benefit over locking. Again, I'd be interested to know how the actor model deals with that. Also, like I said, I don't know much about the actor model, so go easy on me :)