> On Oct. 31, 2013, 6:19 a.m., Benjamin Hindman wrote:
> > 3rdparty/libprocess/include/process/shared.hpp, line 175
> > <https://reviews.apache.org/r/15112/diff/2/?file=374598#file374598line175>
> >
> >     Do we need any memory fencing here?
> 
> Jie Yu wrote:
>     I thought about this when coding. My conclusion is that we should not 
> have a memory consistency issue here. Even if some reads after the read of 
> 'upgraded' here are reordered (i.e., executed before the read of 'upgraded'), 
> it won't cause any problem because we don't rely on 'upgraded' to establish 
> order between reads and writes to any other locations.
>     
>     Thoughts?

Marked 'upgraded' as volatile to prevent compiler from caching its value.


- Jie


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


On Oct. 31, 2013, 5:13 p.m., Jie Yu wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15112/
> -----------------------------------------------------------
> 
> (Updated Oct. 31, 2013, 5:13 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman, Ben Mahler, Vinod Kone, and Jiang 
> Yan Xu.
> 
> 
> Repository: mesos-git
> 
> 
> Description
> -------
> 
> See summary.
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/include/process/shared.hpp faa11cc 
>   3rdparty/libprocess/src/tests/shared_tests.cpp e520b4f 
> 
> Diff: https://reviews.apache.org/r/15112/diff/
> 
> 
> Testing
> -------
> 
> make check
> 
> 
> Thanks,
> 
> Jie Yu
> 
>

Reply via email to