[concurrency] Issues with the current concurrency mechanisms in Python

Christopher Reay christopherreay at gmail.com
Wed Feb 15 12:11:27 CET 2012


Have you checked out the stuff on STM going on in pypy-dev?

There are (and im paraphrasing, but ill try and keep it shallow) something
like 4 styles of STM in current pure CS thinking (STM being quite new). The
discussion on that thread has arrived at something like "its better to
implicitly have all mutations within transactions" and then allow those
transactions to attempt to automatically resolve any conflicts.

2) Concurrent access to mutable objects is *much*, *much* harder than
>   memory management.
> 3) Threading (whether done with OS or userland threads) expose every object
>   in the program to concurrent access.


This is in contrast with what you mentioned here, about concurrent access
to objects, where, in the standard threading/lock model, all mutations are
carried out in a non-deterministic space (which is generally not what
people want. It can take developers some time to learn and understand that
they are operating in a non-deterministic space which isnt convergent with
their imagination of what "should" be happening).

If you think it is in topic, Ill go and try and dig out the STM thread from
pypy an post it somewhere


Also I thought that somewhere in this thread is buried the idea that
processes and threads are different ("but equal") models of concurrency.
Threads suffer from the problem that (by default) "all objects are
accesible [for concurrent mutation]" and processes that "no objects are
accesible [for concurrent mutation]"

As far as I can dig it, the requirement for managing concurrent access to
objects within a threaded application is some kind of reflection of the
requirement for sharing concurrent access to objects across processes. The
issues here are that threading (certainly for Python) is fundamentally
limited to running on a single core, and can require dancing around the GIL
if multiple processes are accessing our python state concurrently.

Christopher
(must get back to work)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/concurrency-sig/attachments/20120215/19392e99/attachment.html>


More information about the concurrency-sig mailing list