4 ms·

These days it would likely be best to implement pthread-win32 mutexes using WaitOnAddress.

• deleted 8y ago
  [deleted]
• dragontamer 8y ago
  Huh, I didn't know about this new primitive. Thanks! It seems to have been introduced into Windows 8 and later, as a competitor against Linux's futex. I did a brief search online, and Raymond Chen had this to say: https://blogs.msdn.microsoft.com/oldnewthing/20160825-00/?p=94165 https://blogs.msdn.microsoft.com/oldnewthing/20160825-00/?p=... > [snip] in real life, you should just use Enter­Critical­Section because it has stuff like spin counts and lock convoy resistance. Is there anything that pthread_mutex_lock does that EnterCriticalSection doesn't do? It seems like a good "translation" to me. I'd only use the WaitOnAddress thing if pthread_mutex_lock had some features that a raw EnterCriticalSection wouldn't do.
  • caf 8y ago
    You need to be able to link your pthread condition variable implementation to your pthread mutex implementation such that a pthread_cond_wait() does an atomic wait-on-condition-variable-and-unlock-mutex, noting that another thread can signal the condition variable without holding any mutex. In addition, pthread mutexes can be statically initialised which requires some kind of initialise-on-first-use for those if you implement them using Critical Section objects. I believe WaitOnAddress(), rather than being a "competitor" for futex was actually added (or at least, the underlying infrastructure was) in order to be able to implement futex() in the WSL.
    • dragontamer 8y ago
      Ah yes, I forgot about condition variables. That makes sense then.