On Jan 14, 2008 2:55 PM, Mike Klaas <[EMAIL PROTECTED]> wrote: > On 14-Jan-08, at 1:32 PM, Charles Merriam wrote: > > > Not to be pedantic, but the major concern others are voicing is that > > is that queue size is not reliable and is therefore a potential source > > of hard to find threading bugs by naive users. Why not just rename > > q.size() to the unweildy name of q.est_size()? > > This is a misleading name. The number returned from qsize() [not size > ()] is perfectly reliable, in the sense that it is the exact size of > the queue at some instant in time.
No, you're wrong. In CPython's implementation, it's likely that qsize is implemented by locking the structure and reading a size field, but there are other, more highly concurrent implementations, like Java's ConcurrentLinkedQueue (http://java.sun.com/javase/6/docs/api/java/util/concurrent/ConcurrentLinkedQueue.html) [1], that have to traverse the structure to read its size. Then the returned value can be higher than the number ever "simultaneously" contained in the queue, if some were added and some were removed during the traversal. Furthermore, it's misleading to think of even a locked implementation's result as reliable. Ignoring problems with simultaneity in the presence of threads, the "true" value could easily have changed by the time qsize returns. And if it returns a value that's not accurate, that can hardly be described as reliable. It really is returning an estimate of the size, suitable only for use in performance optimizations where you're prepared to handle it sometimes being wildly wrong. That said, I'm +1 on the current decision to keep it around, with its current name. Users already have to look it up (since it's not spelled len(q)), so they'll hit the warning. [1]: ConcurrentLinkedQueue can't actually implement Queue in its current form because it can't block. Something more like the data structures described at http://www.cs.rochester.edu/research/synchronization/pseudocode/duals.html looks like it could, but I haven't examined the implementation well enough to be sure. Nevertheless, it would be a bad idea to assume such data structures will never be designed. -- Namasté, Jeffrey Yasskin _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
