Reland old fix that was reverted without my knowledge.

base/time_win.cc

Index: base/time_win.cc
===================================================================
--- base/time_win.cc	(revision 82646)
+++ base/time_win.cc	(working copy)
@@ -99,6 +99,7 @@
 const int64 Time::kTimeTToMicrosecondsOffset = GG_INT64_C(11644473600000000);
 
 bool Time::high_resolution_timer_enabled_ = false;
+int Time::high_resolution_timer_activated_ = 0;
 
 // static
 Time Time::Now() {
@@ -162,22 +163,36 @@
 }
 
 // static
-bool Time::ActivateHighResolutionTimer(bool activate) {
-  if (!high_resolution_timer_enabled_)
+bool Time::ActivateHighResolutionTimer(bool activating) {
+  if (!high_resolution_timer_enabled_ && activating)
     return false;
 
   // Using anything other than 1ms makes timers granular
   // to that interval.
   const int kMinTimerIntervalMs = 1;
   MMRESULT result;
-  if (activate)
+  if (activating) {
     result = timeBeginPeriod(kMinTimerIntervalMs);
-  else
+    high_resolution_timer_activated_++;

[jar (doing other things), 2011/05/01 17:42:34]

Should you be concerned with atomic increment and decrement?  Is this guarnateed
to only appear on one thread?

[Mike Belshe, 2011/05/01 21:58:00]

Good point, I'll add atomics.

[Mike Belshe, 2011/05/04 07:23:13]

Actually, Jim - I looked again.  The comments in lines 186-190 explain this, and
the comments in the header file do as well.  This is only used for testing (so
we can verify the high res timer is activated or not), and the comments clearly
say that this can only be used in single-threaded tests.

[jar (doing other things), 2011/05/04 16:08:26]

Ah... I see... sorry for my confusion.

Maybe it would be good to add comments for lines 176 and 189:

  // For tests ONLY.  Not used in production.

I would expect that you'll have to have a suppression in valgrind for this,
since the value will be changed in a race, even though never relied upon. (maybe
you already have a suppression).  Having a local comment would make it clear
that a suppression should be added.

On 2011/05/04 07:23:13, Mike Belshe wrote:

+  } else {
     result = timeEndPeriod(kMinTimerIntervalMs);
+    high_resolution_timer_activated_--;
+  }
   return result == TIMERR_NOERROR;
 }
 
 // static
+bool Time::IsHighResolutionTimerInUse() {
+  // Note:  we should track the high_resolution_timer_activated_ value
+  // under a lock if we want it to be accurate in a system with multiple
+  // message loops.  We don't do that - because we don't want to take the
+  // expense of a lock for this.  We *only* track this value so that unit
+  // tests can see if the high resolution timer is on or off.
+  return high_resolution_timer_enabled_ &&
+      high_resolution_timer_activated_ > 0;
+}
+
+// static
 Time Time::FromExploded(bool is_local, const Exploded& exploded) {
   // Create the system struct representing our exploded time. It will either be
   // in local time or UTC.