[llvm-bugs] [Bug 41323] New: Race condition in steady_clock::now for _LIBCPP_WIN32API

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=41323

            Bug ID: 41323
           Summary: Race condition in steady_clock::now for
                    _LIBCPP_WIN32API
           Product: libc++
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: ivafanas at gmail.com
                CC: llvm-bugs at lists.llvm.org, mclow.lists at gmail.com

Method implementation is:

```
steady_clock::time_point
steady_clock::now() _NOEXCEPT
{
  static LARGE_INTEGER freq;
  static BOOL initialized = FALSE;
  if (!initialized)
    initialized = QueryPerformanceFrequency(&freq); // always succceeds

  LARGE_INTEGER counter;
  QueryPerformanceCounter(&counter);
  return time_point(duration(counter.QuadPart * nano::den / freq.QuadPart));
}
```

And seems like there is a race condition on `freq` and `initialized` variables
if `steady_clock::now` has never been called before new threads creation.

Possible fixes are:

1. use thread local storage for `freq` and `initialized`, but there might be
some problems on Windows XP:
https://reverseengineering.stackexchange.com/questions/14171/thread-local-storage-access-on-windows-xp

2. use `std::call_once` guard, but it is slightly slower than thread local due
to atomic access.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190331/f8f9f1ff/attachment.html>