4 ms·

It's worth noting that condition variables are a finicky interface. Speaking personally, I would typically much rather work with something like a semaphore. I a

It's worth noting that condition variables are a finicky interface. Speaking personally, I would typically much rather work with something like a semaphore. I also feel like I've seen a lot of misuse of condition variables out there.

ComputerGuru 4y ago
Condition variables were the POSIX equivalent to Win32’s WaitForMultipleObjects (and IOCP apis like it). Now both are available on Windows (and my library makes WFMO available on *nix/Linux/macOS). Semaphores alone can’t mimic the same semantics (juggling between multiple, disparate locks/sync objects) without running into a possible race condition unless you have an API that can somehow wait on one of two or more semaphores to become available.
- asveikau 4y ago
  I totally disagree with your assessment. WaitForMultipleObjects enters the kernel every time and blocks on kernel objects. The nearest equivalent is select, poll, epoll, kqueue, etc. Newer innovations like eventfd start to introduce synchronization objects into the mix of what type of kernel object to block on. A Win32 mutex or semaphore is very heavy and typically avoided in a sane high performance application unless you need it to cross process boundaries. A lot of the time (most?) you will want a win32 critical section, which is similar to the modern futex based pthread mutex implementation in that it does not enter the kernel unless there is contention. A pthread condition variable is clumsy. You need to give it an extra mutex and loop etc. It doesn't have any of the simplicity of WaitForMultipleObjects, even with all the faults of that interface of which there are many.
  - ComputerGuru 4y ago
    I was not talking about implementation details but semantics. I agree with what you are saying. My own implementations are user-mode unless sleeping.
- enjoy-your-stay 4y ago
  WaitForMultipleObjects (been in Win32 forever) is not really related to IO completion Ports, whose API came a lot later. My understanding is that condition variables were designed to be a superior alternative to Windows Event objects. I'm glad to read here that others find them fiddly and overly awkward to use since that was also my impression vs the consistent and usually easy to use Windows thread synchronization HANDLE based objects. Dave Cutler definitely did a good job there IMHO.
  - gpderetta 4y ago
    Condition variables predate Windows and its predecessor VMS by many years (they do not predate unix itself but certainly they predate pthreads by decades). In particular pthreads borrowed them from Mesa, but they originally were part of the monitor abstraction designed by Hoare. So they weren't designed to be a superior alternative to windows events; they might be considered an alternative to events in general but I couldn't easily find any history of the events abstraction.

ComputerGuru 4y ago

Condition variables were the POSIX equivalent to Win32’s WaitForMultipleObjects (and IOCP apis like it). Now both are available on Windows (and my library makes WFMO available on *nix/Linux/macOS). Semaphores alone can’t mimic the same semantics (juggling between multiple, disparate locks/sync objects) without running into a possible race condition unless you have an API that can somehow wait on one of two or more semaphores to become available.

asveikau 4y ago
I totally disagree with your assessment. WaitForMultipleObjects enters the kernel every time and blocks on kernel objects. The nearest equivalent is select, poll, epoll, kqueue, etc. Newer innovations like eventfd start to introduce synchronization objects into the mix of what type of kernel object to block on. A Win32 mutex or semaphore is very heavy and typically avoided in a sane high performance application unless you need it to cross process boundaries. A lot of the time (most?) you will want a win32 critical section, which is similar to the modern futex based pthread mutex implementation in that it does not enter the kernel unless there is contention. A pthread condition variable is clumsy. You need to give it an extra mutex and loop etc. It doesn't have any of the simplicity of WaitForMultipleObjects, even with all the faults of that interface of which there are many.
- ComputerGuru 4y ago
  I was not talking about implementation details but semantics. I agree with what you are saying. My own implementations are user-mode unless sleeping.
enjoy-your-stay 4y ago
WaitForMultipleObjects (been in Win32 forever) is not really related to IO completion Ports, whose API came a lot later. My understanding is that condition variables were designed to be a superior alternative to Windows Event objects. I'm glad to read here that others find them fiddly and overly awkward to use since that was also my impression vs the consistent and usually easy to use Windows thread synchronization HANDLE based objects. Dave Cutler definitely did a good job there IMHO.
- gpderetta 4y ago
  Condition variables predate Windows and its predecessor VMS by many years (they do not predate unix itself but certainly they predate pthreads by decades). In particular pthreads borrowed them from Mesa, but they originally were part of the monitor abstraction designed by Hoare. So they weren't designed to be a superior alternative to windows events; they might be considered an alternative to events in general but I couldn't easily find any history of the events abstraction.