Skip to content

Improve comments from #72617, as suggested by RalfJung #73925

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.

Sign up for GitHub

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

Merged
merged 2 commits into from
Jul 4, 2020
Merged

Improve comments from #72617, as suggested by RalfJung #73925

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
aac2f73
Improve comments from https://github.com/rust-lang/rust/pull/72617, a…
eduardosm Jul 1, 2020
0f1adc8
Further improve comments in libstd/panicking.rs.
eduardosm Jul 2, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 9 additions & 4 deletions src/libstd/panicking.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -229,10 +229,10 @@ pub mod panic_count {
thread_local! { static LOCAL_PANIC_COUNT: Cell<usize> = Cell::new(0) }

// Sum of panic counts from all threads. The purpose of this is to have
// a fast path in `is_zero` (which is used by `panicking`). Access to
// this variable can be always be done with relaxed ordering because
// it is always guaranteed that, if `GLOBAL_PANIC_COUNT` is zero,
// `LOCAL_PANIC_COUNT` will be zero.
// a fast path in `is_zero` (which is used by `panicking`). In any particular
// thread, if that thread currently views `GLOBAL_PANIC_COUNT` as being zero,
// then `LOCAL_PANIC_COUNT` in that thread is zero. This invariant holds before
// and after increase and decrease, but not necessarily during their execution.
static GLOBAL_PANIC_COUNT: AtomicUsize = AtomicUsize::new(0);

pub fn increase() -> usize {
Expand Down Expand Up @@ -263,6 +263,11 @@ pub mod panic_count {
// Fast path: if `GLOBAL_PANIC_COUNT` is zero, all threads
// (including the current one) will have `LOCAL_PANIC_COUNT`
// equal to zero, so TLS access can be avoided.
//
// A relaxed atomic load is equivalent to a normal aligned memory read
// (e.g., a `mov` instruction in x86), while a TLS access might require
Copy link
Member

@RalfJung RalfJung Jul 2, 2020 •
edited
Loading

Choose a reason for hiding this comment

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

It is not equivalent. The compiler can optimize relaxed less than it can optimize normal reads.

Another way to see that they are not equivalent: replacing this relaxed access by a normal aligned read would result in Undefined Behavior. If two things are truly equivalent, then replacing one by the other changes nothing.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

What about "In terms of performance, a relaxed atomic load is similar to a normal aligned memory read (e.g., a mov instruction in x86), but with some compiler optimization restrictions."?

Copy link
Member

Choose a reason for hiding this comment

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

That sounds great. :)

// calling a non-inlinable function (such as `__tls_get_addr` when using
// the GD TLS model).
true
} else {
is_zero_slow_path()
Expand Down