-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Race condition in steady_clock::now for _LIBCPP_WIN32API #40668
Comments
This should fix the problem, but I don't have direct access to a Windows box to check. diff --git a/libcxx/src/chrono.cpp b/libcxx/src/chrono.cpp #elif defined(_LIBCPP_WIN32API) +static LARGE_INTEGER
steady_clock::time_point
|
Yes, this fix is ok.
Well, I do not have windows box too. I'm just reviewing libcpp code in order to understand how it is organized. |
Fixed in r357413. |
r357413 changes a invocation of "QueryPerformanceCounter" to instead call "QueryPerformanceFrequency" (note Counter vs. Frequency). Seems like a mistake? |
Oops. r357474 |
Extended Description
Method implementation is:
And seems like there is a race condition on
freq
andinitialized
variables ifsteady_clock::now
has never been called before new threads creation.Possible fixes are:
use thread local storage for
freq
andinitialized
, but there might be some problems on Windows XP:https://reverseengineering.stackexchange.com/questions/14171/thread-local-storage-access-on-windows-xp
use
std::call_once
guard, but it is slightly slower than thread local due to atomic access.The text was updated successfully, but these errors were encountered: