[swift-dev] Thread safety of weak properties

[Greg Parker]

> On Dec 15, 2015, at 5:32 PM, Kevin Ballard <kevin at 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     gparker at apple.com     Runtime Wrangler