从源代码理解atomic为何不是线程安全

纠正一个网上常见的错误的例子:

开文首先我要纠正一个网上常见的关于atomic非线程安全的举例:若是线程 A 调了 getter,与此同时线程 B 、线程 C 都调了 setter——那最后线程 A get 到的值,有3种可能:多是 B、C set 以前原始的值,也多是 B set 的值,也多是 C set 的值。同时,最终这个属性的值,多是 B set 的值,也有多是 C set 的值。因此atomic可并不能保证对象的线程安全。面试

相似的这个例子相信不少人都见过,看起来也很是合理,没什么错;但细琢磨,这个例子自己没问题,但根本不能证实atomic的非线程安全这个观点!因此面试的时候若是举这个例子~~说明你就没明白atomic的非线程安全性!安全

  • 首先你得知道什么是线程不安全,线程的不安全是因为多线程访问和修改共享资源而引发的不可预测的结果(有可能crash)。能够简单理解为咱们拿到的值是错的。这个例子中,若是线程A getter到的值是个错误的值才能说是线程不安全的,但是这个例子就算线程A可能取到好几种值,你能说取值不对吗;不能。因此这个例子是个错误的例子!*误导了我很久;下文中我会举两个正确的例子。

atomic的原子性和nonatomic的非原子性

  • atomic :系统自动生成的getter/setter方法会进行加锁操做;能够理解过读写锁,能够保证读写安全;较耗时;
  • nonatomic : 系统自动生成的getter/setter方法不会进行加锁操做;但速度会更快;\

下面是两个nonatomic和atomic修饰的变量,咱们用代码掩饰其内部实现;bash

@property (nonatomic) UIImage *nonImage;
@property (atomic) UIImage *atomicImage;

//nonatomic的setter和getter实现:
- (void)setNonImage:(UIImage *)nonImage
{
    _nonImage = nonImage;
}
- (UIImage *)nonImage
{
    return _nonImage;
}
//atomic的setter和getter实现:
- (void)setAtomicImage:(UIImage *)atomicImage
{
    @synchronized (self) {
        _atomicImage = atomicImage;
    }
}
- (UIImage *)atomicImage
{
    @synchronized (self) {
        return _atomicImage;
    }
}

复制代码

源代码分析atomic为何不是线程安全

其实如今一想很奇怪,为何要把atomic和线程安全联系在一块儿去探究;atomic只是对属性的getter/setter方法进行了加锁操做,这种安全仅仅是get/set的读写安全,仅此之一,可是线程安全还有除了读写的其余操做,好比:当一个线程正在get/set时,另外一个线程同时进行release操做,可能会直接crash。很明显atomic的读写锁不能保证线程安全。 下面两个例子写的就挺好,挺简单:\多线程

eg1:若是定义属性NSInteger i是原子的,对i进行i = i + 1操做就是不安全的; 由于原子性只能保证读写安全,而该表达式须要三步操做:
一、读取i的值存入寄存器;
二、将i加1;
三、修改i的值;
若是在第一步完成的时候,i被其余线程修改了,那么表达式执行的结果就与预期的不同,也就是不安全的 eg2:async

self.slice = 0;
    dispatch_queue_t queue = dispatch_queue_create("TestQueue", DISPATCH_QUEUE_CONCURRENT);
    dispatch_async(queue, ^{
        for (int i=0; i<10000; i++) {
            self.slice = self.slice + 1;
        }
    });
    dispatch_async(queue, ^{
        for (int i=0; i<10000; i++) {
            self.slice = self.slice + 1;
        }
    });
复制代码

结果多是[10000,20000]之间的某个值,而咱们想要的结果是20000;很明显这个例子就会引发线程隐患,而atomic并不能防止这个问题;因此咱们说atomic不是线程安全;
因此要想真正理解atomic的非线程安全性,必需要去官网查找解释并经过源码分析才行; 在runtime时property的atomic是一个booleau值,是采用spinlock_t锁去实现的;源码分析

id objc_getProperty(id self, SEL _cmd, ptrdiff_t offset, BOOL atomic) {
    if (offset == 0) {
        return object_getClass(self);
    }

    // Retain release world
    id *slot = (id*) ((char*)self + offset);
    if (!atomic) return *slot;
        
    // Atomic retain release world
    spinlock_t& slotlock = PropertyLocks[slot];
    slotlock.lock();
    id value = objc_retain(*slot);
    slotlock.unlock();
    
    // for performance, we (safely) issue the autorelease OUTSIDE of the spinlock.
    return objc_autoreleaseReturnValue(value);
}
static inline void reallySetProperty(id self, SEL _cmd, id newValue, ptrdiff_t offset, bool atomic, bool copy, bool mutableCopy)
{
    if (offset == 0) {
        object_setClass(self, newValue);
        return;
    }

    id oldValue;
    id *slot = (id*) ((char*)self + offset);

    if (copy) {
        newValue = [newValue copyWithZone:nil];
    } else if (mutableCopy) {
        newValue = [newValue mutableCopyWithZone:nil];
    } else {
        if (*slot == newValue) return;
        newValue = objc_retain(newValue);
    }

    if (!atomic) {
        oldValue = *slot;
        *slot = newValue;
    } else {
        spinlock_t& slotlock = PropertyLocks[slot];
        slotlock.lock();
        oldValue = *slot;
        *slot = newValue;        
        slotlock.unlock();
    }

    objc_release(oldValue);
}
复制代码

很明显atomic属性的setter/getter方法都被加了spinlock自旋锁,须要注意的是spinlock已经因为存在优先级反转问题被弃用并用os_unfair_lock替代。既然被弃用了,这里为何还在用;缘由是进入spinlock去看会发现,底层已经被os_unfair_lick替换:ui

using spinlock_t = mutex_tt<LOCKDEBUG>;
class mutex_tt : nocopy_t {
    os_unfair_lock mLock;
 public:
    constexpr mutex_tt() : mLock(OS_UNFAIR_LOCK_INIT) {
        lockdebug_remember_mutex(this);
    }

    constexpr mutex_tt(const fork_unsafe_lock_t unsafe) : mLock(OS_UNFAIR_LOCK_INIT) { }

    void lock() {
        lockdebug_mutex_lock(this);

        os_unfair_lock_lock_with_options_inline
        .
        .
        .
复制代码
相关文章
相关标签/搜索