1. 30 Jul, 2014 2 commits
  2. 27 Jul, 2014 3 commits
  3. 25 Jul, 2014 2 commits
  4. 24 Jul, 2014 2 commits
  5. 23 Jul, 2014 6 commits
  6. 11 Jun, 2014 1 commit
  7. 09 Jun, 2014 1 commit
  8. 05 Jun, 2014 2 commits
  9. 04 Jun, 2014 10 commits
  10. 29 May, 2014 3 commits
  11. 05 May, 2014 6 commits
    • Merge pull request #23 from ckennelly/clock_initialization · e5a43199
      Dominic Hamon authored
      Resolve race on approx_time_ in FastClock.
    • Merge pull request #22 from ckennelly/mutex_initialization · 46507cb2
      Dominic Hamon authored
      Statically initialize benchmark_mutex and extend its lifetime.
    • Merge pull request #21 from ckennelly/issue20 · 276bda99
      Dominic Hamon authored
      Resolve benchmark cleanup race condition in issue #20.
    • Resolve race on approx_time_ in FastClock. · 2c9b29c9
      Chris Kennelly authored
      InitType should hold a lock before storing to approx_time_, which is later
      read by the background worker.  When the worker is actively running (i.e., not
      blocked on bg_cond_) it holds bg_mutex_.
      
      InitType is called during benchmark setup only, so any contention induced for
      the mutex should not have performance/accuracy consequences.
    • Statically initialize benchmark_mutex and extend its lifetime. · 77106c1f
      Chris Kennelly authored
      RunSpecifiedBenchmarks destroys benchmark_mutex before its last usage,
      typically in RemoveBenchmark during cleanup of the BenchmarkFamilies singleton.
    • Resolve benchmark cleanup race condition in issue #20. · 54e18b89
      Chris Kennelly authored
      The multithreaded API for benchmarks provides that teardown can happen in
      thread 0.  For this to be safe, all other threads executing the benchmark
      function need to have exited.  Otherwise, thread 0 may begin to teardown shared
      resources before the other threads have stopped using these resources as they
      are in their last loop of while (KeepRunning()) { ... }.
      
      This change creates a single exit point for KeepRunning() to return false.
      When running a multithreaded benchmark, thread 0 blocks on KeepRunning() until
      all other threads have exited.  This approach allows for there to be no change
      to the user-facing API exemplified in the BM_MultiThreaded example.
  12. 23 Apr, 2014 2 commits