[issue11987] queue.Queue.put should acquire mutex for unfinished_tasks

[patrick vrijlandt]

patrick vrijlandt patrick.vrijla...@gmail.com added the comment:

I agree. Please close the ticket.

Thanks,

Patrick

2011/5/3 Raymond Hettinger rep...@bugs.python.org


 Raymond Hettinger raymond.hettin...@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 rep...@bugs.python.org
 http://bugs.python.org/issue11987
 ___


--
Added file: http://bugs.python.org/file21877/unnamed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11987
___I agree. Please close the 
ticket.divbr/divdivThanks,/divdivbr/divdivPatrickbrbrdiv 
class=gmail_quote2011/5/3 Raymond Hettinger span dir=ltrlt;a 
href=mailto:rep...@bugs.python.org;rep...@bugs.python.org/agt;/spanbr
blockquote class=gmail_quote style=margin:0 0 0 .8ex;border-left:1px #ccc 
solid;padding-left:1ex;br
Raymond Hettinger lt;a 
href=mailto:raymond.hettin...@gmail.com;raymond.hettin...@gmail.com/agt; 
added the comment:br
div class=imbr
gt; This line should be protected by acquiring the all_tasks_done lock.br
br
/divAll of three of the condition variables share the same underlying lock. 
 The increment occurs only with the lock has been acquired.br
div class=imbr
gt; Theoretically, the increment could occur somewhere during task_done()!br
br
/divI don#39;t understand what you mean.  The semantics of task_done() 
method implies that the count gets decremented.br
div class=imbr
gt; Personally, I would like the increment to occur *before*br
gt; instead of *after* _put().br
br
/divThere may be some merit to this but I don#39;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.br

br
I#39;m reluctant to change the order though because the code is already 
published and some user#39;s _put code may be inspecting the unfinished tasks 
count.  I wouldn#39;t want to break that code without good reason.br

br
--br
divdiv/divdiv class=h5br
___br
Python tracker lt;a 
href=mailto:rep...@bugs.python.org;rep...@bugs.python.org/agt;br
lt;a href=http://bugs.python.org/issue11987; 
target=_blankhttp://bugs.python.org/issue11987/agt;br
___br
/div/div/blockquote/divbr/div
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11987] queue.Queue.put should acquire mutex for unfinished_tasks

[Raymond Hettinger]

Changes by Raymond Hettinger raymond.hettin...@gmail.com:


--
resolution:  - invalid
status: open - closed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11987
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11987] queue.Queue.put should acquire mutex for unfinished_tasks

[patrick vrijlandt]

New submission from patrick vrijlandt patrick.vrijla...@gmail.com:

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.

--
components: Library (Lib)
messages: 135063
nosy: patrick.vrijlandt
priority: normal
severity: normal
status: open
title: queue.Queue.put should acquire mutex for unfinished_tasks
type: behavior
versions: Python 3.2

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11987
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11987] queue.Queue.put should acquire mutex for unfinished_tasks

[Raymond Hettinger]

Changes by Raymond Hettinger raymond.hettin...@gmail.com:


--
assignee:  - rhettinger
nosy: +rhettinger

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11987
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11987] queue.Queue.put should acquire mutex for unfinished_tasks

[Raymond Hettinger]

Raymond Hettinger raymond.hettin...@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 rep...@bugs.python.org
http://bugs.python.org/issue11987
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com