OSSpinLock Is Unsafe
John McCall (via Peter Steinberger):
Spin locks are, unfortunately, illegal on iOS, which does not guarantee progress in the face of priority inversion.
OSSpinLock is unsafe unless you can guarantee that all users have the same priority.
also applies to the new MacBooks since they will depress priority and throttle in thermal overload situations.
to compensate, pthread mutexes are 2-2.5x faster than they used to be on new OSs
It’s a shame that this is not documented. But how great is it to see Apple engineers discuss these sorts of details in public?
Update (2015-12-31): Kevin Ballard:
The reason for this comes back to the thread scheduler and QOS. You remember how I said low-priority threads will eventually execute? That’s no longer true with QOS. More specifically, threads in a higher QOS class will never decay to a lower QOS class, and the scheduler will always prioritize runnable threads in a given QOS class before threads in lower classes. And since threads spinning on a spinlock are always runnable, this means that if there’s enough high-QOS threads waiting on a lock held by a lower-QOS thread, the thread that owns the lock will never execute.
[…]
The Obj-C runtime switched to a handoff lock algorithm, where the spinlock is the size of a word and the owning thread actually stores its thread ID in the lock. Threads that block on the lock can then temporarily donate their priority to the thread that owns the lock, which fixes the priority inversion. There’s potential issues when multiple locks are involved, but in practice it works. The only problem with this solution is it relies on private API, and the spinlock implementation itself isn’t public, so there’s no way for third-party code to use these locks.
Update (2022-10-10): See also: Improving Firefox Responsiveness on macOS.
8 Comments RSS · Twitter
[…] OSSpinLock 外，dispatch_semaphore 和 pthread_mutex 性能是最高的。有消息称，苹果在新系统中已经优化了 pthread_mutex 的性能，所以它看上去和 […]
There are several questions on SO. I think they may be related to ths bug:
http://stackoverflow.com/questions/30269243/application-sticks-on-osspinlocklockslow
http://stackoverflow.com/questions/30082371/how-to-debug-syscall-thread-switch-in-ios-8-3?lq=1
http://stackoverflow.com/questions/29624696/syscall-thread-switch-ios-8-3-race-cocoalumberjack-bug-how-to-debug-this?lq=1
We encountered very similiar issue. We use Unity3d game engine with a lot of lplugins and have no access to the source
Also, OpenRadar bug report:
http://openradar.appspot.com/23896366
[…] 除了 OSSpinLock 外，dispatch_semaphore 和 pthread_mutex 性能是最高的。有消息称，苹果在新系统中已经优化了 pthread_mutex 的性能，所以它看上去和 OSSpinLock 差距并没有那么大了。 […]
[…] could lead to a near live-lock and Firefox effectively hanging. This problem with OSSpinLock was known within Apple hence its […]
The irony here is truly off the scale.
The APIs provided for 3rd party use are so slow, that Firefox is using undocumented reverse engineered APIs, that guarantee it could not ship in the App Store and is liable to break at any moment. Recall that Firefox is the descendant of the first successful web-browser, without which there would be no world-wide-web. Without the WWW, arguably Apple would have a much smaller niche product, since the increasing importance of the Web made it possible for many people to move away from Windows. So Apple has no gratitude.
Oh, and the cherry on top is that Microsoft got into massive trouble for reserving special undocumented APIs for performance for use by its software, to unfairly prevent its competitors from providing as performant products. The fact that Apple replicated the IE and Windows situation with Safari and MacOS, after Microsoft was punished for the same behavior, demonstrates its incredible hubris. It's long past time for the Titan to be smitten down.
