My Object pool isnt working

Tim Peters tim_one at email.msn.com
Sat Apr 5 01:56:12 EST 2003


[Nagy László Zsolt]
> Whew! I always thought that I must use locks to access any object in
> Python before I modify it from a thread.

That belief won't get you in trouble, so if you're happy with it, stay there
<wink>.

> Is it possible to append a list or a dictionary from a thread without
> locking it?

Yes.

> What does thread-safe mean here?

Informally, that Python won't blow up -- the internal data structures remain
sane (self-consistent) whether or not you lock.  More formally, they supply
what's called "sequential consistency" in the literature:  the final result
is what you'd see if all operations were carried out one at a time, in order
within each thread's sequence of operations, but where the order across
threads isn't specified.  Internal sanity follows from that, but it's a weak
guarantee for most application-specific needs.

> For example, what would happen if I walk through a list in a for loop
> while another thread modifies the list?

In the thread that's walking the list, you would see an unspecified mixture
of the list's original state, with an unspecified subset of (zero or more
of) the modifications made by the other thread.  Whether that's a strong
enough guarantee for your app's needs depends entirely on what your app
needs, which isn't meant to be flippant.  Sometimes weak guarantees are
adequate, and then giving up stronger guarantees in return for avoiding
locking can be a good tradeoff.  When in any doubt, serialize.  Better
still, use the Queue module and don't play with locks at all yourself (e.g.,
the OP's problem (a pool of objects that expire over time when unused) is
much more easily solved with a Queue.Queue than via the hand-rolled
dicts+semaphores business posted).






More information about the Python-list mailing list