Thread State and the Global Interpreter Lock

[Scott David Daniels]

Afanasiy wrote:
> Are there plans to make the Python interpreter 
> "fully thread safe" in a future version?
> http://www.python.org/doc/current/api/threads.html
I suspect not.  It would be incredibly hard to program.
The rub is that, as a prgrammer, you think in
statements (or perhaps expressions) of the language
being executed, but a "fully threadsafe" system
interleaves execution at a resolution finer than those
elements.  In fact, the interleaving can happen during
the execution of a single Python opcode.

Data structures written by one thread will be seen as
half-updated by another thread.  Modern processors go put
in a lot of effort to make some of their optimizations
such as out-of-order execution appear as if a simple
march of instructions is processed.  They try to make
each operation look like it has either already happened
or has not yet happened.  Python would have to put in
double effort: first to pik and respect orders of
operations in the C code that might allow safe
interleaving (possible, but very hard to do).  Then it
would have to "decorate" the C code with volatility
declarations in order to prevent a C compiler from
optimizing away some of that careful ordering.

Stupid little sample (in fake C):
	...
         lock = 1;    /* A */
         ds[0] = 5;
         ds[1] = -3;
         lock = 0;    /* B */

If lock is not "declared volatile", a C compiler is free
to observe that the assignment at A is not read before
the assignment at B.  Therefore, it can simply skip the
assignment at A, since B will set the final value anyway.
Compilers do this all the time.  So the Python interpretter
would have to not only get the parts of Python opcodes to
interact nicely at the "C" level, it would also have to get
the code to run correctly on all the C compilers that Python
is built with.  The only way to do _that_ is to get very
conservative about what code you write, and I'd expect an
easily measurable drop in the speed of Python code that
reflect a lot of disabled optimizations.  As a very simple
example, imagine one thread writing into a dictionary and
another thread reading that dictionary.  That won't happen
in a single C statement by a lobng shot, but it must appear
to the other thread as if was either yet-to-happen or
had already happened (no intermediate states).

If you want to write thread code that interacts safely,
each thread mostly plays in its own yard anyway.  Why not
just bite the bullet and put two processes up and allow
them to communicate the little bit they must through some
system-mediated communication facility such as sockets, or
shared memory, or ....  You may even get a bigger speed
advantage that way.

Its C code interleaving compiler optimization of its
code from appearing to break the indivisibility of its
instructions.

-Scott David Daniels
Scott.Daniels at Acm.Org