title: Limits of (soft real-time) timing requirements in Windows OS
body: <p>In the company I work for we build machines which are controlled by software running on Windows OS. A C# application communicates with a bus controller (via a DLL). The bus controller runs on a tact time of 15ms. That means, that we get updates of the actual sensors in the system with a heart beat of 15ms from the bus controller (which <em>is</em> real time). </p>
  
  <p>Now, the machines are evolving into a next generation, where we get a new bus controller which runs on a tact of 1ms. Since everybody realizes that Windows is not a real time OS, the question arises: should we move the controlling part of the software to a real time application (on a real time OS, e.g. a (soft) PLC).</p>
  
  <p>If we stay on the windows platform, we do not have guaranteed responsiveness. That on itself is not necessarily a problem; if we miss a few bus cycles (have a few hickups), the machine will just produce slightly slower (which is acceptable).</p>
  
  <p>The part that worries me, is Thread synchronization between the main machine controlling thread, and the updates we receive from the real time controller (every millisecond). </p>
  
  <p>Where can I learn more about how Windows / .NET C# behaves when it goes down the path of thread synchronization on milliseconds? I know that e.g. <code>Thread.Sleep(1)</code> can take up to 15 ms because Windows is preempting other tasks, so how does this reflect when I synchronize between two threads with <code>Monitor.PulseAll</code> every ms? Can I expect the same unpredictable behavior? Is it asking for trouble when I am moving into the soft real time requirements of 1ms in Windows applications? </p>
  
  <p>I hope somebody with experience on these aspects of threading can shed some light on this. If I need to clarify more, by all means, shoot. </p>