> On Dec 15, 2015, at 5:32 PM, Kevin Ballard <ke...@sb.org> wrote: > >> On Tue, Dec 15, 2015, at 01:38 PM, Greg Parker via swift-dev wrote: >> >> Another solution is to use a handoff lock algorithm. This is what libobjc >> does now. The lock owner stores its thread ID in the lock. Each lock waiter >> yields to the owner thread specifically, donating its priority and resolving >> the inversion. This scheme has theoretical holes when multiple locks are >> involved, but in practice we haven't seen any problems. >> >> As far as I know the spinlock that libobjc now uses is not API. > > It's not. I checked earlier today against the copy of the objc runtime I have > (from opensource.apple.com; my copy is slightly out of date, at version 647, > but it's new enough). The runtime defines a type spinlock_t that's backed by > something called os_lock_handoff_s. It also imports a header > <os/lock_private.h>, which is presumably where this type is defined. I > already updated my radar to suggest that perhaps this type would be a good > candidate to expose. > > Incidentally, if I wanted to implement my own spinlock like this, how can you > yield to a specific thread? I'm only aware of pthread_yield_np(), which > doesn't take a target thread.
It uses Mach's thread_switch() and passes a Mach thread port. It also uses a private option flag; I don't know if any of the public ones are good enough to solve the problem. -- Greg Parker gpar...@apple.com Runtime Wrangler _______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
