> On July 31, 2014, 7:04 p.m., Kevin Sweeney wrote:
> > src/main/python/apache/aurora/client/api/updater.py, line 19
> > <https://reviews.apache.org/r/24126/diff/3/?file=646929#file646929line19>
> >
> >     as far as I can tell you're not avoiding a name conflict here by 
> > renaming - mind just using Event?

Sure. 


> On July 31, 2014, 7:04 p.m., Kevin Sweeney wrote:
> > src/main/python/apache/aurora/client/api/updater.py, lines 234-235
> > <https://reviews.apache.org/r/24126/diff/3/?file=646929#file646929line234>
> >
> >     I can't find any documentation that this actually works - in theory 
> > http://hg.python.org/cpython/file/e49efa892efb/Lib/threading.py#l522 should 
> > do it but that makes the assumption that after calling notify_all() the 
> > waiting threads will be immediately scheduled to see the new value of the 
> > event flag before you clear it (because if they don't see it it's a 
> > deadlock).
> >     
> >     It's too bad you can't use Barrier from 3.2. 
> >     
> >     Not sure I have a better solution but seems like a potentially tricky 
> > bug.
> 
> Kevin Sweeney wrote:
>     Rereading it the code does seem correct, since the monitor-protected flag 
> is only checked to determine whether to wait and wait returns as soon as 
> there's a wakeup.

I doubt waiting threads are actually using this flag when awakened. From what I 
can tell, the self._flag is only relevant within the Event itself and serves as 
a check in wait(). I don't see a reason why awakened threads would actually 
need to re-check the flag, the notification call should be just enough for them 
to continue. Otherwise, it would be a perf bottleneck at best.


- Maxim


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/24126/#review49266
-----------------------------------------------------------


On July 31, 2014, 4:38 p.m., Maxim Khutornenko wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24126/
> -----------------------------------------------------------
> 
> (Updated July 31, 2014, 4:38 p.m.)
> 
> 
> Review request for Aurora, Kevin Sweeney, Bill Farner, and Brian Wickman.
> 
> 
> Bugs: AURORA-626
>     https://issues.apache.org/jira/browse/AURORA-626
> 
> 
> Repository: aurora
> 
> 
> Description
> -------
> 
> Adding a wait_for_batch_completion option into parallel updater.
> 
> 
> Diffs
> -----
> 
>   src/main/python/apache/aurora/client/api/updater.py 
> 05b4c0c76ac2a8551f3aa370ab487f9f0802c3dc 
>   src/main/python/apache/aurora/client/api/updater_util.py 
> c5f8f23912701568e1ee6b69186a533fdd29a5d7 
>   src/main/python/apache/aurora/config/schema/base.py 
> 3b90ccb33e6ffef9e14befd42d95b8b8a94e949b 
>   src/test/python/apache/aurora/client/api/test_updater.py 
> 7020712c9f0b33ec29646482517768ccb13e881f 
> 
> Diff: https://reviews.apache.org/r/24126/diff/
> 
> 
> Testing
> -------
> 
> ./pants src/test/python:all
> 
> 
> Thanks,
> 
> Maxim Khutornenko
> 
>

Reply via email to