-
-
Notifications
You must be signed in to change notification settings - Fork 20.8k
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
Fix some race conditions that happen during initialization #73793
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -50,8 +50,8 @@ void Thread::_set_platform_functions(const PlatformFunctions &p_functions) { | |
platform_functions = p_functions; | ||
} | ||
|
||
void Thread::callback(Thread *p_self, const Settings &p_settings, Callback p_callback, void *p_userdata) { | ||
Thread::caller_id = _thread_id_hash(p_self->thread.get_id()); | ||
void Thread::callback(ID p_caller_id, const Settings &p_settings, Callback p_callback, void *p_userdata) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm curious about why this is needed. I mean, if the pointer was only needed for getting the id, this new version seems to be safer. However, in practice There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There's a call to Threading is hard 🥲 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Besides |
||
Thread::caller_id = p_caller_id; | ||
if (platform_functions.set_priority) { | ||
platform_functions.set_priority(p_settings.priority); | ||
} | ||
|
@@ -79,7 +79,7 @@ void Thread::start(Thread::Callback p_callback, void *p_user, const Settings &p_ | |
std::thread empty_thread; | ||
thread.swap(empty_thread); | ||
} | ||
std::thread new_thread(&Thread::callback, this, p_settings, p_callback, p_user); | ||
std::thread new_thread(&Thread::callback, _thread_id_hash(thread.get_id()), p_settings, p_callback, p_user); | ||
thread.swap(new_thread); | ||
id = _thread_id_hash(thread.get_id()); | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The variable is synced with the semaphore. However, I see now that a data race is still possible, if
bool
doesn't provide atomicity guarantees across platforms. Therefore, thinking about this (and similar cases), my abandonedRelaxedFlag
project is relevant (#63189). That one asks the implementation for atomicity, but without acquire-release semantics, which the semaphore is already providing.Thoughts?
P.S.: What was the sanitizer complaint, by the way?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was a standard read/write complaint, it seems like all variable accesses (even to scalars like
int
andbool
) are considered data races unless they're explicitly specified as atomic.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Providing it is an IP hostname resolver, it's not performance critical and any overhead for
SafeFlag
going to be negligible compared to networking.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking about this along the lines of having an idiom for this kind of cases; namely, every time there's a semaphore-paced loop with an exit flag, just use the atomic-but-relaxed version of the flag, without having to pay further attention to the performance considerations.
That said, that can be discussed separately. These changes already have their merit as they are now.