Juce源码分析（四）自旋锁

        上回说到，在多线程中操作共享变量的问题，当单个操作符操作共享变量时，我们可以使用原子操作符来代替普通操作符，以避免当程序指针在操作符内部时，CPU的切换。但这只是针对于单条语句的，倘若我有N条语句为一个不可分割的整体，也就是说不想让他们因为CPU的切换而分批执行，而是让他们一次性执行完毕。举一个比较恰当的例子，有一个数组类型的共享变量，我有N个线程都想遍历这个数组，这就不是单条指令了，而是一个代码块。这时原子操作符就难以到了，因为我这个代码块中除了基本操作还有很多函数的调用，我不可能去到函数里面把里面普通操作符改成原子操作符，而且还有很多函数根本没有源码，而是库，修改里面代码更是不实际。还有一种给代码块加锁的机制，这种加锁的机制更能让我们感到锁的存在。一般都是用像lock（）和unlock（）这样的一对函数给代码块加锁。

       按照锁的机制不同，分为两种锁，自旋锁和互斥锁。自旋锁与互斥锁比较类似，它们都是为了解决对某项资源的互斥使用。无论是互斥锁，还是自旋锁，在任何时刻，最多只能有一个保持者，也就说，在任何时刻最多只能有一个执行单元获得锁。但是两者在调度机制上略有不同。对于互斥锁，如果资源已经被占用，资源申请者只能进入睡眠状态。但是自旋锁不会引起调用者睡眠，如果自旋锁已经被别的执行单元保持，调用者就一直循环在那里看是否该自旋锁的保持者已经释放了锁，"自旋"一词就是因此而得名。

      下面，我们看一下Juce中是如何实现的

     

/************************************************************************/
/* 自旋锁                                                                     */
/************************************************************************/
class SpinLock
{
public:
	void enter() const              //加锁
	{
		if (! tryEnter())
		{
			for (int i = 20; --i >= 0;)
				if (tryEnter())
					return;

			while (! tryEnter())
				Sleep(0);   //提醒cpu重新计算线程优先级  
		}
	}

	bool tryEnter() const
	{
		return lock.compareAndSetBool(1,0);//比较如果为1置0
	}



	void exit() const               //解锁
	{
		lock = 0;

	}


protected:
	mutable Atomic<int> lock;
};

      

        我们可以看到，Juce里面的自旋锁实现还是非常简单的，在自旋锁内部维护了一个共享变量lock，当无论任何一个线程获得锁后，lock会置1，lock置1后其他线程不可访问，当CPU切换时，如果不能获得锁，那么就那里一直循环判断lock是否置0，直到lock被置0，或者程序指针切换到其他线程。

        关于自旋锁的效率问题，由于原子操作符更底层，所以自旋锁的效率肯定是要低于原子操作符的。但就自旋锁和互斥锁两种锁相比较的话，就得看情况了，一般被锁定的代码量较小时，自选锁的优势更加明显，但如果代码较多，那么互斥锁的效率更高一些。