Is there a lightweight signal in WinAPI / C++ on Windows 7?

Question

For a lightweight signal between threads on Windows, WaitOnAddress is the ideal tool starting from Windows 8. I have to support Windows 7 for the time being, and the best improvement I found (both searching around and reading MSDN) over a Win32 API Event is to go with SleepConditionVariableCS.

Here is a minimal example (handle Ctrl-C in a console app):

//HANDLE Signal;  // event
CONDITION_VARIABLE Signal;
CRITICAL_SECTION cs;

BOOL WINAPI CtrlHandler(DWORD ctl){
  switch (ctl) {
    case CTRL_C_EVENT:  /*SetEvent(Signal);*/ WakeConditionVariable(&Signal); return TRUE;
    default:            return FALSE; // pass it to the system
  }
}

int main(){

  //Signal = CreateEventA(NULL, TRUE /*manual-reset event*/, 
  //                       FALSE/*initial nonsignaled*/, "ctrl-c_sig023xgyI8");
  InitializeConditionVariable(&Signal);  InitializeCriticalSection(&cs);
  
  SetConsoleCtrlHandler(CtrlHandler, TRUE) // register CtrlHandler with the system
  // auto hThread = CreateThread(nullptr, 0, worker, nullptr, ..);
  
  //WaitForSingleObject(Signal, INFINITE);
  EnterCriticalSection(&cs);
    SleepConditionVariableCS (&Signal, &cs, INFINITE);
  LeaveCriticalSection(&cs);
  // stop thread, cleanup, CloseHandle(hThread); CloseHandle(Signal);

  return 0;
}

This example forces the "signal" use-case : the system starts a dedicated thread just to run your CtrlHandler (when the user enters Ctrl-C) which gets a chance then to signal the main thread for user-requested stop.

Is there a better (lighter) approach in the Win32 API or C++ (knowing that, of course, C++ has to ultimately go through the Win32 API).

Answer 1

Doesn't look like there is faster than SleepConditionVariableCS/SRW.

And no much difference between these. This shows a slight advantage to SRW (~2%) on my CPU :

int main(int argc, char **argv){

  CONDITION_VARIABLE cv; InitializeConditionVariable(&cv);
  
  //SRWLOCK Signal; InitializeSRWLock(&Signal);
  CRITICAL_SECTION cs; InitializeCriticalSection(&cs);
  //std::mutex mtx;
  //std::condition_variable ccv;

  bool stop_thread = false;
  auto th1 = std::thread([&](){ while(true){ WakeConditionVariable(&cv); if(stop_thread) return; }});
  //auto th1 = std::thread([&](){ while(true){ ccv.notify_one(); if(stop_thread) return; }});

  const int64_t n = 1000 * 1000 * 1000;
  auto start = std::chrono::high_resolution_clock::now();
  for (int64_t i = 0; i < n; i++) {
    //AcquireSRWLockExclusive(&Signal);
    //  SleepConditionVariableSRW(&cv, &Signal, INFINITE, 0);
    //ReleaseSRWLockExclusive(&Signal);
    
    EnterCriticalSection(&cs);
      SleepConditionVariableCS (&cv, &cs, INFINITE);
    LeaveCriticalSection(&cs);
    
    //std::unique_lock lk(mtx);
    //ccv.wait(lk);
  }
  auto elapsed = std::chrono::high_resolution_clock::now() - start;
  stop_thread = true; th1.join();
  double nSec = 1e-6 * std::chrono::duration_cast<std::chrono::microseconds>(elapsed).count();
  printf("%.3lf calls/sec\n", n / nSec);
  
  return 0;
}

std::condition_variable is a good 20% slower.

Bottom line : if you don't need recursion/you have low contention (no Try.. shenanigans for SRW), go with SRW (with NtCreateKeyedEvent special sauce), otherwise use CS.

---- EDIT ----

An other nice tool to consider (it's actually needed in my sample program !) is C++20's std::latch which can be "abused" into a "cooperative WakeOnAddress()" :

std::latch mainCanBeAwakened{1};

BOOL WINAPI CtrlHandler(DWORD ctl){
  ...
    case CTRL_C_EVENT:  mainCanBeAwakened.wait(); // user typing faster than light ?
       WakeConditionVariable(&Signal); return TRUE;
  ...
}

int main(){

  ...  
  EnterCriticalSection(&cs);
    mainCanBeAwakened.count_down(); // call twice (> mainCanBeAwakened.n) for UB !
    SleepConditionVariableCS (&Signal, &cs, INFINITE);
  LeaveCriticalSection(&cs);
  ...
}

main() has to initialize, start workers, .. and wait for Cntl-C last. If it takes time doing that, a Cntl-C can come before the condition variable is Sleeped on, and the WakeConditionVariable() would have no effect on the main() thread. So the CtrlHandler() needs to know that the CV is "altered" (Sleeped on by main()), said differently : it needs to "WakeOnAddress(CV)".

As you can see above, this can be done very economically (resources & code) using a std::latch (which is even lighter than std::barrier) in the absence of WakeOnAddress & SynchronizationBarrier (available in Windows 8+) : InitializeSynchronizationBarrier(2) / EnterSynchronizationBarrier in both threads / DeleteSynchronizationBarrier.

---- EDIT ----

As per Alex's answer, you can further drop CV and CS ! (on Win7 in particular)

I don't think it can possibly get lighter than a naked exclusive Slim RW lock.

It is wiser, though, to let down the latch if you have a dozen locks juggled in a lively thread pool.

Answer 2

If you're looking for a complaint way, you can have Event or Semaphore object, backed by an atomic, with possible spinning. You'll have the part of lightweight-ness of WaitOnAddress that comes from the userspace ops. You still won't save an OS object though.

---

If you're fine with a hacky way, that is against the documentation and is not future-proof, then SRWLOCK is known to behave as a binary semaphore, implying that it can be released not in acquired thread. There's AppVerifier check for that, but still this currently works with this check disabled.

See Can SRW Lock be used as a binary semaphore?

So,

SRWLOCK lock = SRWLOCK_INIT;

BOOL WINAPI CtrlHandler(DWORD ctl){
  switch (ctl) {
    case CTRL_C_EVENT:  ReleaseSRWLockExclusive(&lock); return TRUE;
    default:            return FALSE; // pass it to the system
  }
}

int main(){

  //Signal = CreateEventA(NULL, TRUE /*manual-reset event*/, 
  //                       FALSE/*initial nonsignaled*/, "ctrl-c_sig023xgyI8");

  AcquireSRWLockExclusive(&lock);

 
  SetConsoleCtrlHandler(CtrlHandler, TRUE) // register CtrlHandler with the system
  // auto hThread = CreateThread(nullptr, 0, worker, nullptr, ..);
  
  AcquireSRWLockExclusive(&lock); // again, will be acquired when released in `CtrlHandler`

  return 0;
}