Monday, October 30, 2017 [Tweets] [Favorites]

Locks, Thread Safety, and Swift: 2017 Edition

Mike Ash:

Note that pthread_mutex_t, pthread_rwlock_t, and os_unfair_lock are value types, not reference types. That means that if you use = on them, you make a copy. This is important, because these types can't be copied! If you copy one of the pthread types, the copy will be unusable and may crash when you try to use it. The pthread functions that work with these types assume that the values are at the same memory addresses as where they were initialized, and putting them somewhere else afterwards is a bad idea. os_unfair_lock won't crash, but you get a completely separate lock out of it which is never what you want.

If you use these types, you must be careful never to copy them, whether explicitly with a = operator, or implicitly by, for example, embedding them in a struct or capturing them in a closure.

Additionally, since locks are inherently mutable objects, this means you need to declare them with var instead of let.

[…]

You must be careful with the pthread locks, because you can create a value using the empty () initializer, but that value won't be a valid lock. These locks must be separately initialized using pthread_mutex_init or pthread_rwlock_init[…]

Previously: Locks, Thread Safety, and Swift, OSSpinLock Is Unsafe, os_unfair_lock.

Comments

Stay up-to-date by subscribing to the Comments RSS Feed for this post.

Leave a Comment