Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Fix an ordering bug in Global::push_bag() #53
In an RFC (https://github.com/crossbeam-rs/rfcs/blob/master/text/2017-07-23-relaxed-memory.md), we explained why Crossbeam is correct in relaxed memory. However, the pseudocode in the RFC and the implementation differs: in
Unfortunately, the current implementation is incorrect. For example, consider the following scenario:
This PR fixes it by reordering
Arguably, the performance remains almost the same after this PR. This is an one-time measurement of
This PR is blocked by #52: here I just commented out
I must say I'm a little confused by this (although it's probably correct :).
Does the fence in
I must admit the semantics of
The semantics of
Assuming the semantics presented in those papers are correct, the semantics of
Basically that's why we need to wait for 2 epoch advances. The RFC I mentioned above (https://github.com/crossbeam-rs/rfcs/blob/master/text/2017-07-23-relaxed-memory.md) explains in fuller details of its correctness.
I see. So in this PR, thread B is the one in
@martinhath I'm sorry for the delay.
I'm sorry again that I couldn't fully understand your comment.. I presumed A is the one in
Instead of directly answering your question, I'd like to summarize what's going on in the proof in https://github.com/crossbeam-rs/rfcs/blob/master/text/2017-07-23-relaxed-memory.md . In essence, the reasoning depends on the following two properties of SC fences:
So the proof first (1) somehow deduces that
I hope it helps, at least a little bit. Please feel free to ask any questions.