<html>
    <head>
      <base href="https://bugs.llvm.org/">
    </head>
    <body><table border="1" cellspacing="0" cellpadding="8">
        <tr>
          <th>Bug ID</th>
          <td><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - steady_clock not advancing after system resumes"
   href="https://bugs.llvm.org/show_bug.cgi?id=44773">44773</a>
          </td>
        </tr>

        <tr>
          <th>Summary</th>
          <td>steady_clock not advancing after system resumes
          </td>
        </tr>

        <tr>
          <th>Product</th>
          <td>libc++
          </td>
        </tr>

        <tr>
          <th>Version</th>
          <td>unspecified
          </td>
        </tr>

        <tr>
          <th>Hardware</th>
          <td>Macintosh
          </td>
        </tr>

        <tr>
          <th>OS</th>
          <td>MacOS X
          </td>
        </tr>

        <tr>
          <th>Status</th>
          <td>NEW
          </td>
        </tr>

        <tr>
          <th>Severity</th>
          <td>normal
          </td>
        </tr>

        <tr>
          <th>Priority</th>
          <td>P
          </td>
        </tr>

        <tr>
          <th>Component</th>
          <td>All Bugs
          </td>
        </tr>

        <tr>
          <th>Assignee</th>
          <td>unassignedclangbugs@nondot.org
          </td>
        </tr>

        <tr>
          <th>Reporter</th>
          <td>philwill@fb.com
          </td>
        </tr>

        <tr>
          <th>CC</th>
          <td>llvm-bugs@lists.llvm.org, mclow.lists@gmail.com
          </td>
        </tr></table>
      <p>
        <div>
        <pre>On macOS pre-Catalina we see that in some cases std::steady_clock::now() either
reverses or does not advance after the system resumes from sleep. I cannot
reproduce this effect on Catalina.

I speculate that pre-Catalina CLOCK_UPTIME_RAW was very close to the raw output
of the `RDTSC` instruction and is therefore reset to zero in some "deeper"
sleep states where the CPUs are powered-down. The circumstantial evidence for
this is that we were never able to reproduce the issue with short periods of
sleep on macs that are plugged in to an electricity supply, whereas it occurred
most often in the wild on Monday mornings when people open laptop lids after
the weekend.

I'm reporting it here because it seems to me that the current implementation of
std::steady_clock does not meet the standard's requirement that it should
"advance at a steady rate relative to real time" at least on macOS Mojave.

Workaround
==========

We have addressed this in our application by providing our own steady_clock
that's based on CLOCK_MONOTONIC_RAW.

Proposed Fix
============
I leave it to the libc++ team to decide whether to make a similar change to the
standard library - I appreciate that it's a difficult balance given the
precision concerns mentioned in <a href="https://reviews.llvm.org/D27429">https://reviews.llvm.org/D27429</a>

Testing CLOCK_MONOTONIC_RAW on Catalina I do not encounter repeating timestamps
at nanosecond resolution so it appears that Apple have addressed that concern
mentioned in D27429.

Application-level Symptoms
==========================
In our application this manifested in a few ways. The most-obvious was very
high CPU usage after resume. When we grabbed a CPU profile it showed that we
were burning time in the spinning part of a hybrid lock - it tries to spin for
5 microseconds before suspending. Because `std::steady_clock::now()` was not
advancing it did not ever meet the condition to stop spinning.

We also saw this as bugs where scheduled work was not happening after the
desired time in our work scheduler; it would happen much later if at all.</pre>
        </div>
      </p>


      <hr>
      <span>You are receiving this mail because:</span>

      <ul>
          <li>You are on the CC list for the bug.</li>
      </ul>
    </body>
</html>