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

[atomics] Replace 'could' and 'might' #4348

Merged
merged 1 commit into from Nov 13, 2020
Merged

Conversation

jensmaurer
Copy link
Member

as directed by ISO/CS.

Partially addresses #4319

source/atomics.tex Outdated Show resolved Hide resolved
source/atomics.tex Outdated Show resolved Hide resolved
are lock-free can depend on the alignment of the referenced object.
For example, it is possible for
operations on a \tcode{std::complex<double>} object
to be lock-free only if the object is aligned to \tcode{2*alignof(double)}.
Copy link
Member

Choose a reason for hiding this comment

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

This seems to be ambiguous now. "It is possible for X only if Y" can be read as "if and only if Y".

This ISO rule is stupid.

How about "For example, operations on std::complex<double> objects can be lock-free if aligned to 2*alignof(double) but the hardware can require a lock when aligned to alignof(double)."

I really thing "might" is a better word for what we're trying to say.

Copy link
Member

Choose a reason for hiding this comment

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

Completely agree about the stupidity of the rule. But I have argued, my face is blue, and we got no closer to publishing the standard. :(

I don't like using "can" for possibility rather than ability or capability. How about this:

"For example, there might exist hardware that supports lock-free atomic operations on std::complex<double> objects only if those objects are aligned to 2*alignof(double)."

Copy link
Contributor

Choose a reason for hiding this comment

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

That uses "might", which are also being replaced.

Copy link
Member Author

Choose a reason for hiding this comment

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

I don't like using "can" for possibility rather than ability or capability.

@zygoloid : Sorry, now I'm confused. Your initial mail gave the guidance "Use "can" when referring to ability or possibility in all cases." This clearly says "possibility", it seems.

Copy link
Member

@zygoloid zygoloid Nov 13, 2020

Choose a reason for hiding this comment

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

You're right, that's what ISO/CS wanted. Doesn't mean that I necessarily like the outcome though :) Sometimes the use of "can" for both capability and possibility leaves it ambiguous which one is meant.

@JohelEGP Curses. But I think that's fairly easy to fix: "For example, it is possible that the hardware supports lock-free atomic operations on std::complex<double> objects only if those objects are aligned to 2*alignof(double)."

Copy link
Member Author

Choose a reason for hiding this comment

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

fixed

Copy link
Member

Choose a reason for hiding this comment

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

It now mixes plural and singular. It starts talking about objects (plural) then says "only if the object" (singular). Richard's "only if those objects are aligned" seems right to me.

Apart from that, this looks good now.

Copy link
Member Author

Choose a reason for hiding this comment

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

Good point, but we should go singular instead. Fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants