Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update docs of 'fence' #41217

Merged
merged 1 commit into from
May 3, 2017
Merged

Conversation

topecongiro
Copy link
Contributor

This PR updates the docs for std::sync::atomic::fence with an example and a diagram.
Part of #29377.
r? @steveklabnik

@steveklabnik
Copy link
Member

@Amanieu, would you mind reviewing this? Or at least, someone other than me should make sure it's accurate. This isn't my area of specialty.

@Amanieu
Copy link
Member

Amanieu commented Apr 11, 2017

The example looks correct, and the explanation seems to be correct as well.

@Amanieu
Copy link
Member

Amanieu commented Apr 11, 2017

Actually, I think the unsafe impl are not necessary, they are already implemented by AtomicBool.

@alexcrichton alexcrichton added the A-docs Area: documentation for any part of the project, including the compiler, standard library, and tools label Apr 11, 2017
@topecongiro
Copy link
Contributor Author

Thanks for comments! Removed unsafe impls from the example.

/// A fence 'A' which has [`Release`] ordering semantics, synchronizes with a
/// fence 'B' with (at least) [`Acquire`] semantics, if and only if there exists
/// atomic operations X and Y, both operating on some atomic object 'M' such
/// that A is sequenced before X, Y is synchronized before B and Y observes
/// the change to M. This provides a happens-before dependence between A and B.
///
/// Thread 1 Thread 2
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Travis build is failing due to this line. I removed this line on my local environment and ./x.py test src/libcore completed successfully. Is this a bug, or intended?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CommonMark considers indented text to be code:

http://spec.commonmark.org/0.27/#indented-code-blocks

As a result, it attempts to run this as a Rust program:

Thread 1                                          Thread 2

and that's not a valid Rust program :)

The best idea I have here is to wrap this diagram in three backticks and annotate with 'ignore' as seen here: (ignore the backslashes)

/// \```ignore
///     Thread 1                                          Thread 2
///
/// ...
/// ...
///
/// \```

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@frewsxcv Thank you!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately,

/// \```ignore
/// ...
/// \```

didn't work (the document got corrupted).
Instead, I tried ```text and it worked fine.

@frewsxcv frewsxcv added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Apr 14, 2017
Copy link

@ghost ghost left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have just a few minor nits...

The explanation and examples are correct.
Love the ASCII drawing and the example! It'd be good to see more of these. :)

/// fences when the certain condition is met. Also, a fence prevents reordering
/// of operations around a fence by CPU or a compiler. Each behavior is
/// controlled by the value of [`Ordering`].
///
/// A fence 'A' which has [`Release`] ordering semantics, synchronizes with a
Copy link

@ghost ghost Apr 17, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps this should say "A fence 'A' which has (at least) [Release]..."? Note the text in parentheses.

@@ -1550,12 +1550,30 @@ unsafe fn atomic_xor<T>(dst: *mut T, val: T, order: Ordering) -> T {

/// An atomic fence.
///
/// A fence creates happens-before edges between other atomic operations or
Copy link

@ghost ghost Apr 17, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/edges/dependence/ or s/edges/relationships/

A fence creates happens-before relationships between not only atomic operations and fences, but also between normal memory operations.

/// A fence creates happens-before edges between other atomic operations or
/// fences when the certain condition is met. Also, a fence prevents reordering
/// of operations around a fence by CPU or a compiler. Each behavior is
/// controlled by the value of [`Ordering`].
Copy link

@ghost ghost Apr 17, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: If you wish, you may rephrase this along the lines of: "Also, depending on the specified order, a fence prevents certain types of memory operation reorderings around it by CPU or compiler."

@arielb1
Copy link
Contributor

arielb1 commented Apr 18, 2017

@steveklabnik are you looking at this?

@steveklabnik
Copy link
Member

I am not sure if @stjepang 's nits should be addressed before merging or not, basically.

@topecongiro
Copy link
Contributor Author

@stjepang Thank you for your feedbacks!

@topecongiro
Copy link
Contributor Author

Is it ok to reflect the nits?

@steveklabnik
Copy link
Member

steveklabnik commented Apr 19, 2017 via email

@topecongiro
Copy link
Contributor Author

Sorry for being lazy... I pushed the changes suggested by @stjepang. Thanks again!

Copy link

@ghost ghost left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking good - just a few more grammar fixes, and then this is ready to go! :)
Thanks so much for taking an effort to improve the docs!

/// A fence creates happens-before relationships between other atomic operations or
/// fences when the certain condition is met. Also, depending of the specified
/// `order`, a fence prevents reordering certain types of memory operations
/// around a fence by CPU or a compiler.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/a fence/it/

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@stejpang Thank you for your advices! One question, are you referring to the last a fence, or the second and the last ones?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just meant "around a fence" -> "around it". :)
But now that I think more about this, how about the following (slightly simplified) paragraph?

"Depending on the specified order, a fence prevents the compiler and CPU from reordering certain types of memory operations around it. That creates synchronizes-with relationships between it and atomic operations or fences in other threads."

I think here it's more correct to talk about synchronizes-with rather than happens-before. Pretty much every two operations within a single thread already have a happens-before relationship.
Fences really just establish synchronizes-with relationships with fences/atomics in other threads.

See the following links for a clearer explanation:
http://preshing.com/20130702/the-happens-before-relation/
http://preshing.com/20130823/the-synchronizes-with-relation/

Sorry for being so pedantic :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with you, since rust does not have a signal and fence prohibits Relaxed ordering.
Thank you very much for your explanation!

/// fence 'B' with (at least) [`Acquire`] semantics, if and only if there exists
/// atomic operations X and Y, both operating on some atomic object 'M' such
/// A fence creates happens-before relationships between other atomic operations or
/// fences when the certain condition is met. Also, depending of the specified
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/of/on/

///
/// A fence 'A' which has (at least) [`Release`] ordering semantics, synchronizes
/// with a fence 'B' with (at least) [`Acquire`] semantics, if and only if there
/// exists operations X and Y, both operating on some atomic object 'M' such
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/exists/exist/

@arielb1
Copy link
Contributor

arielb1 commented May 2, 2017

@steveklabnik I think the nits were addressed. Can you look at this?

@arielb1 arielb1 added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels May 2, 2017
@steveklabnik
Copy link
Member

@bors: r+ rollup

thank you so much, and sorry about all of the delays.

@bors
Copy link
Contributor

bors commented May 2, 2017

📌 Commit 91a9866 has been approved by steveklabnik

frewsxcv added a commit to frewsxcv/rust that referenced this pull request May 3, 2017
…eveklabnik

Update docs of 'fence'

This PR updates the docs for `std::sync::atomic::fence` with an example and a diagram.
Part of rust-lang#29377.
r? @steveklabnik
bors added a commit that referenced this pull request May 3, 2017
Rollup of 7 pull requests

- Successful merges: #41217, #41625, #41640, #41653, #41656, #41657, #41705
- Failed merges:
@bors bors merged commit 91a9866 into rust-lang:master May 3, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-docs Area: documentation for any part of the project, including the compiler, standard library, and tools S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants