Multithreading and Queue

[Tim Peters]

[Jeffrey Barish]
> Several methods in Queue.Queue have warnings in their doc strings that they
> are not reliable (e.g., qsize).  I note that the code in all these methods
> is bracketed with lock acquire/release.  These locks are intended to
> protect the enclosed code from collisions with other threads.  I am
> wondering whether I understand correctly that the reason these methods are
> still not reliable is that from the point where a thread calls qsize (for
> example) to the point in Queue where a thread acquires a lock there is a
> bunch of code, none of which is protected by a lock, (and moreover there is
> another bunch of code between the point where a thread releases a lock and
> then actually returns to the calling program) and so despite the locks in
> Queue it is still possible for values to change before a thread acts on
> them.

Pretty much, yes.  qsize() knows perfectly well what the exact size of
the queue is at the time it computes it, but by the time qsize's
_caller_ gets the result, any number of other threads may have run for
any amount of time, so the actual size of the queue at the instant the
caller uses the result may be anything whatsoever.  A specific
application may be able to get stronger guarantees by disciplining its
use of threads in exploitable ways, but nothing stronger can be said
in the _general_ case.