5 ms·

If you don't need fairness, don't use a fair lock. The default assumption should be fairness because it doesn't require you to think (just like the default tra

If you don't need fairness, don't use a fair lock. The default assumption should be fairness because it doesn't require you to think (just like the default transaction isolation level should be serializable). As the blog post points out, OS X provides unfair mutexes too. Windows locks are fair by default too, BTW (IIRC anyway). People just use the unfair version when they need performance.

striking 10y ago
http://www.pcdoctor-community.com/wp/posts/2007/10/fairness-in-win32-lock-objects/ http://www.pcdoctor-community.com/wp/posts/2007/10/fairness-... Windows XP tried to implement some amount of fairness in its locks but did not guarantee it. Windows Vista gave up on fairness entirely. You should just be using unfair locks. Thread starvation is rare in most OSes at this point.
- eridius 10y ago
  Thread starvation is still very much a thing on a lot of devices. macOS and iOS even have a Quality Of Service implementation in the kernel specifically to ensure that high-priority threads get to run when they'd otherwise be starved, and this can lead to low-priority threads being suspended for many seconds at a time under high workload. In fact, it's now really dangerous to use a regular spinlock on iOS and macOS because you can get into a priority inversion livelock if threads from different QoS levels are contending the same lock. The Obj-C runtime was seeing delays of tens of seconds in some cases when using spinlocks, so it now uses a private "os_lock" which is a spinlock that uses SPI to "donate" the QoS of the waiting thread to the one that holds the spinlock.
  - LeoNatan25 10y ago
    As of iOS 10 and macOS 10.12, it is no longer private: `os_unfair_lock`. https://developer.apple.com/reference/os/os_unfair_lock https://developer.apple.com/reference/os/os_unfair_lock
    - eridius 10y ago
      Oh good! I'll have to do some research at some point to find out if this is literally the same thing as the os_lock that the Obj-C runtime uses, but either way, I'm glad it's available now.
      - LeoNatan25 10y ago
        It uses the same private API (or at least, what you described in your previous post).

striking 10y ago

http://www.pcdoctor-community.com/wp/posts/2007/10/fairness-in-win32-lock-objects/ http://www.pcdoctor-community.com/wp/posts/2007/10/fairness-... Windows XP tried to implement some amount of fairness in its locks but did not guarantee it. Windows Vista gave up on fairness entirely. You should just be using unfair locks. Thread starvation is rare in most OSes at this point.

eridius 10y ago
Thread starvation is still very much a thing on a lot of devices. macOS and iOS even have a Quality Of Service implementation in the kernel specifically to ensure that high-priority threads get to run when they'd otherwise be starved, and this can lead to low-priority threads being suspended for many seconds at a time under high workload. In fact, it's now really dangerous to use a regular spinlock on iOS and macOS because you can get into a priority inversion livelock if threads from different QoS levels are contending the same lock. The Obj-C runtime was seeing delays of tens of seconds in some cases when using spinlocks, so it now uses a private "os_lock" which is a spinlock that uses SPI to "donate" the QoS of the waiting thread to the one that holds the spinlock.
- LeoNatan25 10y ago
  As of iOS 10 and macOS 10.12, it is no longer private: `os_unfair_lock`. https://developer.apple.com/reference/os/os_unfair_lock https://developer.apple.com/reference/os/os_unfair_lock
  - eridius 10y ago
    Oh good! I'll have to do some research at some point to find out if this is literally the same thing as the os_lock that the Obj-C runtime uses, but either way, I'm glad it's available now.
    - LeoNatan25 10y ago
      It uses the same private API (or at least, what you described in your previous post).