Skip to content

Ensure sequential consistency in fallback implementation when requested#38

Open
taylordotfish wants to merge 2 commits into
Amanieu:masterfrom
taylordotfish:master
Open

Ensure sequential consistency in fallback implementation when requested#38
taylordotfish wants to merge 2 commits into
Amanieu:masterfrom
taylordotfish:master

Conversation

@taylordotfish

Copy link
Copy Markdown

As discussed in #37, use Ordering::SeqCst when unlocking the spinlock if the corresponding atomic operation had a requested ordering of SeqCst. Otherwise, the existing Release ordering should be fine. The lock operation can remain unconditionally Acquire; it always occurs as part of an “atomic” lock/unlock pair.

@Amanieu

Amanieu commented Sep 29, 2023

Copy link
Copy Markdown
Owner

GCC's libatomic does things differently: it effectively inserts a fence(SeqCst) both before acquiring the lock and after releasing it.

I am not completely sure which approach is the correct one.

Use `SeqCst` for both acquiring and releasing the spinlock when the
corresponding atomic operation is `SeqCst`. This may not be strictly
necessary, but it can't hurt.
@taylordotfish

Copy link
Copy Markdown
Author

Well, I should probably trust GCC's developers' understanding of atomics more than my own, and in any case, the extra assurance can't hurt, so I've modified the PR to acquire the lock with SeqCst when appropriate, as well.

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.

2 participants