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

FEXCore: Implements an efficient spin-loop API #3337

Closed
wants to merge 1 commit into from

Conversation

Sonicadvance1
Copy link
Member

This will only be used internally inside of FEXCore for efficient shared codecach backpatch spin-loops.

Copy link
Member

@neobrain neobrain left a comment

Choose a reason for hiding this comment

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

Went over this for a general first pass.

As usual newly added abstractions can be reviewed more effectively when there's code that actually uses them, so a follow-up draft PR for the adapted backpatching would help here.

class FutexSpinWait final {
public:
#ifdef _M_ARM_64
template<typename T, typename TT>
Copy link
Member

Choose a reason for hiding this comment

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

Why do we need different integer-sizes for this?

Copy link
Member Author

Choose a reason for hiding this comment

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

Because the following idiom is the expected use-case and enforcing an integer literal on the second argument is a pita.

uint8_t *VariablePtr;
FEXCore::Utils::FutexSpinWait::Wait(VariablePtr, 0);

This will only be used internally inside of FEXCore for efficient shared
codecach backpatch spin-loops.
Sonicadvance1 added a commit to Sonicadvance1/FEX that referenced this pull request Dec 18, 2023
To show the usage of the efficient spin-loop API for FEX-Emu#3337

Doesn't guarantee any safety becuase currently code isn't shared between
threads and that's going to take more time to implement.
@Sonicadvance1
Copy link
Member Author

Went over this for a general first pass.

As usual newly added abstractions can be reviewed more effectively when there's code that actually uses them, so a follow-up draft PR for the adapted backpatching would help here.

#3338
There you go.

@neobrain
Copy link
Member

#3338 There you go.

Thanks, but there was no confusion on the intended usage of the new API. Before adding new code for a primitive, I think it's reasonable to have a concrete use case where it's demonstrably a better solution than the alternatives to justify its addition.

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