[Python-Dev] Software Transactional Memory for Python

[Armin Rigo]

Hi Nick,

On Sat, Aug 27, 2011 at 2:40 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 1. How does the patch interact with C code that explicitly releases
> the GIL? (e.g. IO commands inside a "with atomic:" block)

As implemented, any code in a "with atomic" is prevented from
explicitly releasing and reacquiring the GIL: the GIL remain acquired
until the end of the "with" block.  In other words
Py_BEGIN_ALLOW_THREADS has no effect in a "with" block.  This gives
semantics that, in a full multi-core STM world, would be implementable
by saying that if, in the middle of a transaction, you need to do I/O,
then from this point onwards the transaction is not allowed to abort
any more.  Such "inevitable" transactions are already supported e.g.
by RSTM, the C++ framework I used to prototype a C version
(https://bitbucket.org/arigo/arigo/raw/default/hack/stm/c ).

> 2. Whether or not Jython and IronPython could implement something like
> that, since they're free threaded with fine-grained locks. If they
> can't then I don't see how we could justify making it part of the
> standard library.

Yes, I can imagine some solutions.  I am no Jython or IronPython
expert, but let us assume that they have a way to check synchronously
for external events from time to time (i.e. if there is some
equivalent to sys.setcheckinterval()).  If they do, then all you need
is the right synchronization: the thread that wants to start a "with
atomic" has to wait until all other threads are paused in the external
check code.  (Again, like CPython's, this not a properly multi-core
STM-ish solution, but it would give the right semantics.  (And if it
turns out that STM is successful in the future, Java will grow more
direct support for it <wink>))


A bientôt,

Armin.