[Python] locks in threads

In article <3A02BBE7.E58CD78D at ira.uka.de>,
Markus von Ehr wrote:
If the reader thread is only reading one variable (and never updates
that variable), you don't need a lock. If your thread is reading
multiple variables and you don't need a consistent state between the
variables, you don't need a lock (e.g. for certain kinds of screen
updating).

But if any of the following is true, you need a lock:

* you need consistant data across multiple variables
* more than one thread writes to the variables
* you are updating a complex structure with internal state (this
explicitly includes lists and dictionaries -- there are some exceptions,
but a lock is safer unless you *really* know what you're doing)

Note that you can run into problems with references across threads, so
you need to be careful.

Note that you don't need a lock in this case, as long
as you store all the data in a Wrapper object, and
have a method to get a copy of the object, and another
method to set the object.

Later,
Blake.

In article <slrn9089tk.l4j.bwinton at tor.dhs.org>,
Blake Winton wrote:
I believe you're wrong. Consider the following trivial example:

class Foo:
def set (self, x, y):
self.x = x
self.y = y
def get (self):
return (x, y)

If thread 1 calls Foo.set() and thread 2 calls Foo.get(), it is possible
for the return to be executed after setting self.x but before setting
self.y. Now, one could in theory do this

class Foo:
def set (self, x, y):
(self.x, self.y) = (x, y)
def get (self):
return (x, y)

but I'm not a fan of relying implicitly on a coding convention in
multi-threaded programs. Far better to just use a lock in case the
program changes later.

Just checking, but did you mean return(self.x,self.y) instead ?

In article <mailman.973400357.13037.python-list at python.org>,
Rodrigo Senra wrote:
Um, yeah. Whoops!