title: What's the standard approach to making calculations thread-safe?
body: <p>What initially seemed like a problem with an easy solution has proven to be quite an interesting challenge.</p>
  
  <p>I have a class which maintains an internally fixed-size, thread-safe collection (by way of using <code>lock</code> on all insertion and removal operations) and provides various statistical values via its properties.</p>
  
  <p>One example:</p>
  
  <pre><code>public double StandardDeviation {
      get {
          return Math.Sqrt((Sum2 - ((Sum * Sum) / Count)) / Count);
      }
  }
  </code></pre>
  
  <p>Now, I've tested this computation thoroughly, running 10,000 values through the collection and checking the standard deviation on each update. It works fine... in a single-threaded scenario.</p>
  
  <p>A problem arises in the multi-threaded context of our development and production environments, however. It seems that this number is somehow <em>sometimes</em> coming back <code>NaN</code> before quickly changing back to a real number. Naturally this must be due to a negative value passed to <code>Math.Sqrt</code>. I can only imagine this happens when, mid-calculation, one of the values used in the calculation is updated by a separate thread.</p>
  
  <p>I could cache the values first:</p>
  
  <pre><code>int C = this.Count;
  double S = this.Sum;
  double S2 = this.Sum2;
  
  return Math.Sqrt((S2 - (S * S) / C) / C);
  </code></pre>
  
  <p>But then <code>Sum2</code> might still be updated, for example, after <code>S = this.Sum</code> has been set, compromising the calculation once again.</p>
  
  <p>I could put a <code>lock</code> around all points in the code where these values are updated:</p>
  
  <pre><code>protected void ItemAdded(double item) {
      // ...
  
      lock (this.CalculationLock) {
          this.Sum += item;
          this.Sum2 += (item * item);
      }
  }
  </code></pre>
  
  <p>Then if I <code>lock</code> on this same object when calculating <code>StandardDeviation</code>, I <em>thought</em> that would, finally, fix the problem. It didn't. The value is still coming in as <code>NaN</code> on a fleeting, infrequent basis.</p>
  
  <p>Frankly, even if the above solution <em>had</em> worked, it was very messy and did not seem very manageable to me. <strong>Is there a standard and/or more straightforward way of achieving thread-safety in calculated values such as this?</strong></p>
  
  <hr>
  
  <p><strong>EDIT</strong>: Turns out here we have an example of a problem where it seemed at first like there was only one possible explanation when, after all, the issue was with something else entirely.</p>
  
  <p>I had been meticulous about implementing thread safety in every way I could without making a huge performance sacrifice if at all possible -- locking on reads and writes to shared values (e.g., <code>Sum</code> and <code>Count</code>), caching values locally, and using the same lock object for modifying the collection and updating the shared values... honestly, it all seemed like overkill.</p>
  
  <p>Nothing worked; that nefarious <code>NaN</code> kept popping up. So I decided to print all the values in the collection to the console whenever <code>StandardDeviation</code> returned <code>NaN</code>...</p>
  
  <p>Immediately I noticed that it always seemed to be happening <em>when all the values in the collection were the same</em>.</p>
  
  <p>It's official: I got burned by floating point arithmetic. (All of the values were the same, so the radicand in <code>StandardDeviation</code> -- i.e., the number whose square root is being taken -- was being evaluated to some extremely small negative number.)</p>