homepage

Line 154 in standard library's queue.py, in the definition of Queue.put() is: 
self.unfinished_tasks += 1
This line should be protected by acquiring the all_tasks_done lock.
Theoretically, the increment could occur somewhere during task_done()!
Additional note:
Personally, I would like the increment to occur *before* instead of *after* _put(). This is because I would like to be able to implement a _put() that does not put everything. This put should be able to undo the increment. As it is, calling task_done() from put might decrease the counter to zero inadvertently.

> This line should be protected by acquiring the all_tasks_done lock.
All of three of the condition variables share the same underlying lock. The increment occurs only with the lock has been acquired. 
> Theoretically, the increment could occur somewhere during task_done()!
I don't understand what you mean. The semantics of task_done() method implies that the count gets decremented.
> Personally, I would like the increment to occur *before* 
> instead of *after* _put().
There may be some merit to this but I don't see how it matters much since both occur within the context of the same lock being held. A user defined method can still add or subtract any number it wants from the unfinished task count. The result of +1 -5 is the same as -5 +1.
I'm reluctant to change the order though because the code is already published and some user's _put code may be inspecting the unfinished tasks count. I wouldn't want to break that code without good reason.

I agree. Please close the ticket.
Thanks,
Patrick
2011年5月3日 Raymond Hettinger <report@bugs.python.org>
>
> Raymond Hettinger <raymond.hettinger@gmail.com> added the comment:
>
> > This line should be protected by acquiring the all_tasks_done lock.
>
> All of three of the condition variables share the same underlying lock.
> The increment occurs only with the lock has been acquired.
>
> > Theoretically, the increment could occur somewhere during task_done()!
>
> I don't understand what you mean. The semantics of task_done() method
> implies that the count gets decremented.
>
> > Personally, I would like the increment to occur *before*
> > instead of *after* _put().
>
> There may be some merit to this but I don't see how it matters much since
> both occur within the context of the same lock being held. A user defined
> method can still add or subtract any number it wants from the unfinished
> task count. The result of +1 -5 is the same as -5 +1.
>
> I'm reluctant to change the order though because the code is already
> published and some user's _put code may be inspecting the unfinished tasks
> count. I wouldn't want to break that code without good reason.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue11987>
> _______________________________________
>