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

Making sure the thread-local lock registration data is moving to the core the suspended HPX thread is resumed on #4610

Merged
merged 1 commit into from May 14, 2020

Conversation

hkaiser
Copy link
Member

@hkaiser hkaiser commented May 10, 2020

Currently, if a lock is actively ignored while the executing thread is suspended, then the lock is not properly de-registered if the thread is resumed on a different core. This PR fixes the issue by moving the lock registration data to a different core with the executing thread.

msimberg
msimberg previously approved these changes May 11, 2020
Copy link
Contributor

@msimberg msimberg left a comment

Choose a reason for hiding this comment

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

Thanks!

@msimberg
Copy link
Contributor

I was about to write a bunch of questions since I didn't see how this could work. Now I think I see how it works, but I'll ask the questions anyway to make sure it's what's actually happening. By putting on_exit_reset_held_locks_data around thread yielding you're effectively making the ignored and held locks HPX thread-local rather than worker thread-local? And therefore you don't get into trouble with multiple HPX threads ignoring different sets of locks on the same worker thread, or other locks being ignored on the worker thread to which an HPX thread with ignored locks gets moved?

@hkaiser
Copy link
Member Author

hkaiser commented May 11, 2020

I was about to write a bunch of questions since I didn't see how this could work. Now I think I see how it works, but I'll ask the questions anyway to make sure it's what's actually happening. By putting on_exit_reset_held_locks_data around thread yielding you're effectively making the ignored and held locks HPX thread-local rather than worker thread-local? And therefore you don't get into trouble with multiple HPX threads ignoring different sets of locks on the same worker thread, or other locks being ignored on the worker thread to which an HPX thread with ignored locks gets moved?

That is the idea, yes.

@hkaiser hkaiser force-pushed the fixing_lock_registration branch 3 times, most recently from 12a31d0 to 9305191 Compare May 12, 2020 00:29
the core the suspended HPX thread is resumed on
@msimberg msimberg merged commit 62c825f into master May 14, 2020
@msimberg msimberg deleted the fixing_lock_registration branch May 14, 2020 07:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants