Document the semantics of fences.
Add atomic_load and atomic_store, explaining why exist.
Define the synchronizes-with relationship.
Reorder and revise some of the existing text.
Details
Details
- Reviewers
jhb kib - Group Reviewers
manpages - Commits
- rS326982: Document the semantics of atomic_thread_fence operations.
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
| share/man/man9/atomic.9 | ||
|---|---|---|
| 64 ↗ | (On Diff #36691) | atomic_load() is still only a patch. |
| 221 ↗ | (On Diff #36691) | I know that this is an explicit rule e.g. in the ARM memory model. Are you sure that e.g. PowerPC ISA v3.0 store release has the same requirement ? I mean, we indeed provide the release causality (is this the common term ?) due to using too strong barriers. I do not remember such requirement in the C11 text, but I may be wrong there for sure. If C/C++ model require such visibility, then I definitely do not object. |
| 240 ↗ | (On Diff #36691) | I understand the intent but it probably should say "program' memory". The x86 store/load barrier used e.g. by seq_cst fence does access a memory. |
| share/man/man9/atomic.9 | ||
|---|---|---|
| 64 ↗ | (On Diff #36691) | I've taken for granted that we are going to commit it. |
| 221 ↗ | (On Diff #36691) | I have not looked at the PowerPC v3.0 ISA. However, in general, you need this "causality" in order to claim that any execution of a properly synchronized program under release consistency will be equivalent to some legal execution under sequential consistency. Consider the "task queue" example that I mentioned in email last week. For the memory holding the task itself to be consistent after a long chain of enqueues and/or dequeues by various threads between the task's enqueue and its dequeue, you need causality. In particular, the threads in the middle of the chain will never actually read from the stores that defined the task, but nevertheless these stores will have to become visible through the acquires and releases by those threads. In essence, what I've tried to do here is describe in simple terms the effects of the happens before ordering without actually defining it. |
| share/man/man9/atomic.9 | ||
|---|---|---|
| 223 ↗ | (On Diff #36691) | I'm tempted to tweak this, and say, "... observe these stores ..." |
| 240 ↗ | (On Diff #36691) | Let me think about this point. I'm not sure that adding the word "program" will really have the intended effect. I could alternatively try to describe fences as having no side effects on memory except to control ordering. |
Comment Actions
This is definitely a large improvement over the existing text!
| share/man/man9/atomic.9 | ||
|---|---|---|
| 223 ↗ | (On Diff #36691) | Agreed with adding "these" |
Comment Actions
When did we introduces fences? A statement should probably be added to the HISTORY section.