.NET EventWaitHandle 慢

Question

I'm using waveOutWrite with a callback function, and under native code everything is fast. Under .NET it is much slower, to the point I think I'm doing something very wrong, 5 or 10 times slower sometimes.

I can post both sets of code, but seems like too much, so I'll just post the C code that is fast and point out the minor variances in the .NET code.

HANDLE WaveEvent;
const int TestCount = 100;
HWAVEOUT hWaveOut[1]; // don't ask why this is an array, just test code
WAVEHDR woh[1][20];

void CALLBACK OnWaveOut(HWAVEOUT,UINT uMsg,DWORD,DWORD,DWORD)
{
   if(uMsg != WOM_DONE)
      return;
   assert(SetEvent(WaveEvent)); // .NET code uses EventWaitHandle.Set()
}

void test(void)
{
   WaveEvent = CreateEvent(NULL,FALSE,FALSE,NULL);
   assert(WaveEvent);

   WAVEFORMATEX wf;
   memset(&wf,0,sizeof(wf));
   wf.wFormatTag =  WAVE_FORMAT_PCM;
   wf.nChannels = 1;
   wf.nSamplesPerSec = 8000;
   wf.wBitsPerSample = 16;
   wf.nBlockAlign = WORD(wf.nChannels*(wf.wBitsPerSample/8));
   wf.nAvgBytesPerSec = (wf.wBitsPerSample/8)*wf.nSamplesPerSec;

   assert(waveOutOpen(&hWaveOut[0],WAVE_MAPPER,&wf,(DWORD)OnWaveOut,0,CALLBACK_FUNCTION) == MMSYSERR_NOERROR);

   for(int x=0;x<2;x++)
      {
      memset(&woh[0][x],0,sizeof(woh[0][x]));
      woh[0][x].dwBufferLength = PCM_BUF_LEN;
      woh[0][x].lpData = (char*) malloc(woh[0][x].dwBufferLength);
      assert(waveOutPrepareHeader(hWaveOut[0],&woh[0][x],sizeof(woh[0][x])) == MMSYSERR_NOERROR);
      assert(waveOutWrite(hWaveOut[0],&woh[0][x],sizeof(woh[0][x])) == MMSYSERR_NOERROR);
      }

   int bufferIndex = 0;
   DWORD times[TestCount];
   for(int x=0;x<TestCount;x++)
      {
      DWORD t = timeGetTime();
      assert(WaitForSingleObject(WaveEvent,INFINITE) == WAIT_OBJECT_0); // .NET code uses EventWaitHandle.WaitOne()
      assert(woh[0][bufferIndex].dwFlags & WHDR_DONE);
      assert(waveOutWrite(hWaveOut[0],&woh[0][bufferIndex],sizeof(woh[0][bufferIndex])) == MMSYSERR_NOERROR);
      bufferIndex = bufferIndex == 0 ? 1 : 0;
      times[x] = timeGetTime() - t;
      }
}

The times[] array for the C code always has values around 80, which is the PCM buffer length I am using. The .NET code also shows similar values sometimes, however, it sometimes shows values as high as 1000, and more often values in the 300 to 500 range.

Doing the part that is in the bottom loop inside the OnWaveOut callback instead of using events, makes it fast all the time, with .NET or native code. So it appears the issue is with the wait events in .NET only, and mostly only when "other stuff" is happening on the test PC -- but not a lot of stuff, can be as simple as moving a window around, or opening a folder in my computer.

Maybe .NET events are just really bad about context switching, or .NET apps/threads in general? In the app I'm using to test my .NET code, the code just runs in the constructor of a form (easy place to add test code), not on a thread-pool thread or anything.

I also tried using the version of waveOutOpen that takes an event instead of a function callback. This is also slow in .NET but not in C, so again, it points to an issue with events and/or context switching.

I'm trying to keep my code simple and setting an event to do the work outside the callback is the best way I can do this with my overall design. Actually just using the event driven waveOut is even better, but I tried this other method because straight callbacks are fast, and I didn't expect normal event wait handles to be so slow.

Answer 1

Maybe not 100% related but I faced somehow the same issue: calling EventWaitHandle.Set for X times is fine, but then, after a threshold that I can't mention, each call of this method takes 1 complete second!

Is appears that some .net way to synchronize thread are much slower than the ones you use in C++.

The all mighty @jonskeet once made a post on his web site ( https://jonskeet.uk/csharp/threads/waithandles.html ) where he also refers the very complex concept of .net synchronization domains explained here: https://www.drdobbs.com/windows/synchronization-domains/184405771

He mentions that .net and the OS must communicate in a very very very time precise way with object that must be converted from one environment to another. All this is very time consuming.

I summarized a lot here, not to take credit for the answer but there is an explanation. There are some recommendations here ( https://docs.microsoft.com/en-us/dotnet/standard/threading/overview-of-synchronization-primitives ) about some ways to choose how to synchronize depending on the context, and the performance aspect is mentioned a little bit.