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

From tbb::atomic to std::atomic #1908

Closed
wants to merge 1 commit into from

Conversation

boberfly
Copy link
Contributor

Description of Change(s)

Swaps out tbb::atomic with std::atomic, with the help of the people in #1471

_PrototypeTask and _Entry structs need defined copy/move constructors to be able to compile (std::atomic has copy deleted and move undefined). The adding into a TfHashMap with a make_pair is considered a move.

Fixes Issue(s)

  • I have submitted a signed Contributor License Agreement

@@ -286,22 +286,36 @@ class UsdImaging_ResolvedAttributeCache
// non-time varying data, entries may exist in the cache with invalid
// values. The version is used to determine validity.
struct _Entry {
_Entry()
_Entry() noexcept
Copy link
Member

Choose a reason for hiding this comment

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

Could you comment on the addition of the noexcept keyword here? I'm not sure I'm spotting what necessitates the change?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh right I think it'll still compile without it and we don't necessarily need it here, it is to imply the move will always be a move and not a copy. Maybe just have it for move and not the regular constructor?

Copy link
Member

@meshula meshula left a comment

Choose a reason for hiding this comment

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

Every change looks like the appropriate one to one modification to std::atomic. I left one question about the addition of the noexcept keyword.

@jilliene
Copy link

Filed as internal issue #USD-7438

@meshula
Copy link
Member

meshula commented Jun 23, 2022

Hi @boberfly! Thanks for the PR, it's very much appreciated!

As noted in the issue thread by @e4lam (#1471 (comment)) , it makes sense to add #include <atomic> to the pch.h files where tbb/atomic.h was removed.

In order to facilitate merging this work, could we ask that it be broken up such that individual modules can be independently regression and performance tested at our end, and merged one by one?

The set of commits that would enable that would be the affected modules and their pch.h files, and then lastly the remainder of the pch.h changes.

(1) pcp
(2) sdf
(3) usdGeom
(4) usdImaging
(5) all the <tbb/atomic.h> --> in one last batch

Apologies for the inconvenience, and thank you for the work!

@boberfly
Copy link
Contributor Author

@meshula no worries I'll get to this soon

@FlorianZ
Copy link
Contributor

FlorianZ commented Aug 26, 2022

@boberfly, any updates on this? Thank you!

Copy link
Contributor

@brechtvl brechtvl left a comment

Choose a reason for hiding this comment

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

I submitted this as various individual pull requests as was requested here. Those also includes a correction for the inline code comment I left.

Comment on lines +376 to +378
unsigned cv = _cacheVersion.load();
if (v < _cacheVersion
&& entry->version.compare_and_swap(_cacheVersion, v) == v)
&& entry->version.compare_exchange_strong(cv, v))
Copy link
Contributor

@brechtvl brechtvl May 21, 2023

Choose a reason for hiding this comment

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

The argument order here is wrong and leads to a deadlock in the tests. This works:

&& entry->version.compare_exchange_strong(v, _cacheVersion.load())

Copy link
Member

Choose a reason for hiding this comment

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

Thank you so much, @brechtvl - I see it in the smaller PR.

@spiffmon
Copy link
Member

spiffmon commented Jun 3, 2023

Am I correct in thinking that this PR has now been superseded by the other PR's and we should close this one out?

@brechtvl
Copy link
Contributor

brechtvl commented Jun 5, 2023

Yes, I think this one can be closed.

@spiffmon
Copy link
Member

spiffmon commented Jun 5, 2023

Closing in favor of more targeted PR's.

@spiffmon spiffmon closed this Jun 5, 2023
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.

7 participants