# Thread safety of weak properties

**URL:** <https://forums.swift.org/t/thread-safety-of-weak-properties/422>\
**Category:** Compiler\
**Created:** [December 11, 2015, 2:50am UTC](https://forums.swift.org/t/thread-safety-of-weak-properties/422 "2015-12-11T02:50:53Z")\
**Posts on this page:** 1\
**Showing post:** 7

<div class="post-metadata">

**Author:** ![John\_McCall](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/john_mccall/32/1351_2.png) [@John\_McCall](https://forums.swift.org/u/John_McCall)\
**Post date:** [December 14, 2015, 5:47pm UTC](https://forums.swift.org/t/thread-safety-of-weak-properties/422/7 "2015-12-14T17:47:01Z")

</div>

> #3 sounds like a great approach to me. I agree with Kevin that if we keep the object husk approach that any use of a weak pointer that returns nil should drop any reference to a husk.

Spin locks are, unfortunately, illegal on iOS, which does not guarantee progress in the face of priority inversion.

John.

> **···**
>
> > On Dec 12, 2015, at 7:04 PM, Chris Lattner \<clattner@apple.com\> wrote:
> 
> > -Chris
> > 
> > > On Dec 11, 2015, at 7:00 AM, Mike Ash via swift-dev \<swift-dev@swift.org\> wrote:
> > > 
> > > 3. Borrow a bit from the weak pointer to implement a spinlock. This is really a special case of (2), with the activity count being capped at 1 and additional activity blocking. In fact, you could even do a hybrid approach by borrowing more bits. (I think it could safely steal up to 20 bits with current 64-bit architectures. This may not be wise. As long as targets are pointer-aligned you can safely steal 2/3 bits.)

---

_[View the full topic](https://forums.swift.org/t/thread-safety-of-weak-properties/422)._