Because of multithreading semantics, this is not reliable.
grante at visi.com
Wed May 3 22:41:49 CEST 2006
On 2006-05-03, OlafMeding at gmail.com <OlafMeding at gmail.com> wrote:
> Because of multithreading semantics, this is not reliable.
> This sentence is found in the Python documentation for "7.8.1
> Queue Objects".
> This scares me! Why would Queue.qsize(), Queue.empty( ), and a
> Queue.full() not be reliable?
IIRC from the last time this question came up, what the doc
means by "not reliable" is that the result you get is accurate
at the time of the call (for the period the call is inside in
the mutex-protected region), but the saved result may not be
correct at some point in the future because some other thread
may have done an operation on the queue.
I've argued that the "not reliable" phrase is simply wrong: IMO
the calls _are_ reliable: they always return the correct value
at the time the call was made (for my previous definition of
"at the time the call was made"). That's "reliable" in my book.
I've no idea why anybody would ever expect Queue.qsize() to
return the size of the queue as it was going to be at some
undetermined point in the future.
If we were to use the "not reliable" semantics that are used in
the Queue docs, pretty much everything is "not reliable" in a
multi-threading environment. For example binding a global name
to an object is "not reliable" in a multi-threaded environment
because another thread can re-bind it later to a different
object. I think describing that problem as "global name
binding is not reliable in a multi-threaded environment" is
> Looking at the source code of Queue.py, all 3 calls use a
> mutex (based on thread.allocate_lock()). Does this mean that
> the thread.allocate_lock() mechanism is not reliable (scary
> indeed) or does this have to do with other implementation
IMO, it has to do with a poor choice of language.
> Many thanks for explaining this mystery.
Grant Edwards grante Yow! Mr and Mrs PED, can I
at borrow 26.7% of the RAYON
visi.com TEXTILE production of the
More information about the Python-list