To be fair, the sharing of data between threads is no different from
other concerns about global state. The only thing threads change is
that you can have multiple functions doing stuff at once.
state = [1,2,3]
def func():
state[1] += 5
# do work
state[1] -= 5
It occurs to me that threads must have some state of their own. For
instance, if I have two thread and they are both in that same function
above, one thread needs to know that it is currently on the bytecode for the
first statement, and the other needs to know that it is in the bytecode for
some of the # do work. In other words, each thread has a current instruction
pointer.
If the thread has a current instruction pointer, then it must also know what
function it is currently in, and therfore have a pointer (or some such) to
the current function locals:
def func1():
ham = 0.0;
ham += 1; // thread 1 here
def func2():
ham = 0.0;
ham -= 1; // thread 2 here
In my C++ understanding of threads, those manipulations on ham won't
interact. I would hope this is also true in Python?
If I'm right that a thread knows what function it is in, and therefore has
function-level state access to the current function, then I'd think that it
also has to have module level state. After all, functions occur inside
modules, or at least they can:
spam.py:
ham = 0.0;
def func():
ham += 1; // thread 1 here
eggs.py:
ham = 0.0;
def func():
ham -= 1; // thread 2 here
Here I would again hope that the simultaneous threads would not cause
collisions on ham, since (I think?) there should be spam.ham and eggs.ham,
which would be two separate things.
The worry I can see is if the CPython interpreter has taken some shortcuts
and has global variables for the pointers to the module globals and the
funciton locals. In that case, if two threads aren't in the same function I
can see all hell breaking loose pretty easily.
Loren
--
https://mail.python.org/mailman/listinfo/python-list
