Message135064
| Author |
rhettinger |
| Recipients |
patrick.vrijlandt, rhettinger |
| Date |
2011年05月03日.19:46:42 |
| SpamBayes Score |
8.463782e-05 |
| Marked as misclassified |
No |
| Message-id |
<1304452003.26.0.946138390442.issue11987@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
> 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. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2011年05月03日 19:46:43 | rhettinger | set | recipients:
+ rhettinger, patrick.vrijlandt |
| 2011年05月03日 19:46:43 | rhettinger | set | messageid: <1304452003.26.0.946138390442.issue11987@psf.upfronthosting.co.za> |
| 2011年05月03日 19:46:42 | rhettinger | link | issue11987 messages |
| 2011年05月03日 19:46:42 | rhettinger | create |
|