为什么使用等待队列的时候要用lock自旋锁

为什么使用等待队列的时候要用lock自旋锁

队列特点是先进先出，在任务调度时，有时候需要保证先进入的任务先执行，所以需要使用队列。

自旋锁(spin lock) 自旋锁与互斥锁有点类似，只是自旋锁不会引起调用者睡眠，如果自旋锁已经被别的执行单元保持，调用者就一直循环在那里看是 否该自旋锁的保持者已经释放了锁，"自旋"一词就是因此而得名。其作用是为了解决某项资源的互斥使用。因为自旋锁不会引起调用者睡眠，所以自旋锁的效率远 高于互斥锁。虽然它的效率比互斥锁高，但是它也有些不足之处： 1、自旋锁一直占用cpu，他在未获得锁的情况下，一直运行－－自旋，所以占用着cpu，如果不能在很短的时 间内获得锁，这无疑会使cpu效率降低。 2、在用自旋锁时有可能造成死锁，当递归调用时有可能造成死锁，调用有些其他函数也可能造成死锁，如 copy_to_user()、copy_from_user()、kmalloc()等。 因此我们要慎重使用自旋锁，自旋锁只有在内核可抢占式或smp的情况下才真正需要，在单cpu且不可抢占式的内核下，自旋锁的操作为空操作。自旋锁适用于锁使用者保持锁时间比较短的情况下。 两种锁的加锁原理 互斥锁：线程会从sleep（加锁）——>running（解锁），过程中有上下文的切换，cpu的抢占，信号的发送等开销。 自旋锁：线程一直是running(加锁——>解锁)，死循环检测锁的标志位，机制不复杂。 互斥锁属于sleep-waiting类型的锁。例如在一个双核的机器上有两个线程(线程a和线程b)，它们分别运行在core0和 core1上。假设线程a想要通过pthread_mutex_lock操作去得到一个临界区的锁，而此时这个锁正被线程b所持有，那么线程a就会被阻塞 (blocking)，core0 会在此时进行上下文切换(context switch)将线程a置于等待队列中，此时core0就可以运行其他的任务(例如另一个线程c)而不必进行忙等待。而自旋锁则不然，它属于busy-waiting类型的锁，如果线程a是使用pthread_spin_lock操作去请求锁，那么线程a就会一直在 core0上进行忙等待并不停的进行锁请求，直到得到这个锁为止。 两种锁的区别 互斥锁的起始原始开销要高于自旋锁，但是基本是一劳永逸，临界区持锁时间的大小并不会对互斥锁的开销造成影响，而自旋锁是死循环检测，加锁全程消耗cpu，起始开销虽然低于互斥锁，但是随着持锁时间，加锁的开销是线性增长。 两种锁的应用 互斥锁用于临界区持锁时间比较长的操作，比如下面这些情况都可以考虑 1 临界区有io操作 2 临界区代码复杂或者循环量大 3 临界区竞争非常激烈 4 单核处理器 至于自旋锁就主要用在临界区持锁时间非常短且cpu资源不紧张的情况下，自旋锁一般用于多核的服务器。 lock与syntronized的区别 转自自： java并发之lock与synchronized的区别 1）lock是一个接口，而synchronized是java中的关键字，synchronized是内置的语言实现； 2）synchronized在发生异常时，会自动释放线程占有的锁，因此不会导致死锁现象发生；而lock在发生异常时，如果没有主动通过unlock()去释放锁，则很可能造成死锁现象，因此使用lock时需要在finally块中释放锁； 3）lock可以让等待锁的线程响应中断，而synchronized却不行，使用synchronized时，等待的线程会一直等待下去，不能够响应中断； 4）通过lock可以知道有没有成功获取锁，而synchronized却无法办到。 5）lock可以提高多个线程进行读操作的效率。 在性能上来说，如果竞争资源不激烈，两者的性能是差不多的，而当竞争资源非常激烈时（即有大量线程同时竞争），此时lock的性能要远远优于synchronized。所以说，在具体使用时要根据适当情况选择。 两者在锁的相关概念上区别： 1.可重入锁 如果锁具备可重入性，则称作为可重入锁。像synchronized和reentrantlock都是可重入锁，可重入性在我看来实际上表明了锁的分配机制：基于线程的分配，而不是基于方法调用的分配。举个简单的例子，当一个线程执行到某个synchronized方法时，比如说method1，而在method1中会调用另外一个synchronized方法method2，此时线程不必重新去申请锁，而是可以直接执行方法method2。 看下面这段代码就明白了： 1 2 3 4 5 6 7 8 9 class myclass { public synchronized void method1() { method2(); } public synchronized void method2() { } } 上述代码中的两个方法method1和method2都用synchronized修饰了，假如某一时刻，线程a执行到了method1，此时线程a获取了这个对象的锁，而由于method2也是synchronized方法，假如synchronized不具备可重入性，此时线程a需要重新申请锁。但是这就会造成一个问题，因为线程a已经持有了该对象的锁，而又在申请获取该对象的锁，这样就会线程a一直等待永远不会获取到的锁。 而由于synchronized和lock都具备可重入性，所以不会发生上述现象。 2.可中断锁 可中断锁：顾名思义，就是可以相应中断的锁。 在java中，synchronized就不是可中断锁，而lock是可中断锁。 如果某一线程a正在执行锁中的代码，另一线程b正在等待获取该锁，可能由于等待时间过长，线程b不想等待了，想先处理其他事情，我们可以让它中断自己或者在别的线程中中断它，这种就是可中断锁。 在前面演示lockinterruptibly()的用法时已经体现了lock的可中断性。 3.公平锁 公平锁即尽量以请求锁的顺序来获取锁。比如同是有多个线程在等待一个锁，当这个锁被释放时，等待时间最久的线程（最先请求的线程）会获得该所，这种就是公平锁。 非公平锁即无法保证锁的获取是按照请求锁的顺序进行的。这样就可能导致某个或者一些线程永远获取不到锁。 在java中，synchronized就是非公平锁，它无法保证等待的线程获取锁的顺序。 而对于reentrantlock和reentrantreadwritelock，它默认情况下是非公平锁，但是可以设置为公平锁。 看一下这2个类的源代码就清楚了： 在reentrantlock中定义了2个静态内部类，一个是notfairsync，一个是fairsync，分别用来实现非公平锁和公平锁。 我们可以在创建reentrantlock对象时，通过以下方式来设置锁的公平性： 1 reentrantlock lock = new reentrantlock(true); 如果参数为true表示为公平锁，为fasle为非公平锁。默认情况下，如果使用无参构造器，则是非公平锁。 另外在reentrantlock类中定义了很多方法，比如： isfair() //判断锁是否是公平锁 islocked() //判断锁是否被任何线程获取了 isheldbycurrentthread() //判断锁是否被当前线程获取了 hasqueuedthreads() //判断是否有线程在等待该锁 在reentrantreadwritelock中也有类似的方法，同样也可以设置为公平锁和非公平锁。不过要记住，reentrantreadwritelock并未实现lock接口，它实现的是readwritelock接口。 4.读写锁 读写锁将对一个资源（比如文件）的访问分成了2个锁，一个读锁和一个写锁。 正因为有了读写锁，才使得多个线程之间的读操作不会发生冲突。 readwritelock就是读写锁，它是一个接口，reentrantreadwritelock实现了这个接口。 可以通过readlock()获取读锁，通过writelock()获取写锁。 性能比较 在jdk1.5中，synchronized是性能低效的。因为这是一个重量级操作，它对性能最大的影响是阻塞的是实现，挂起线程和恢复线程的操作都需要转入内核态中完成，这些操作给系统的并发性带来了很大的压力。相比之下使用java提供的lock对象，性能更高一些。brian goetz对这两种锁在jdk1.5、单核处理器及双xeon处理器环境下做了一组吞吐量对比的实验，发现多线程环境下，synchronized的吞吐量下降的非常严重，而reentranklock则能基本保持在同一个比较稳定的水平上。但与其说reetrantlock性能好，倒不如说synchronized还有非常大的优化余地，于是到了jdk1.6，发生了变化，对synchronize加入了很多优化措施，有自适应自旋，锁消除，锁粗化，轻量级锁，偏向锁等等。导致在jdk1.6上synchronize的性能并不比lock差。官方也表示，他们也更支持synchronize，在未来的版本中还有优化余地，所以还是提倡在synchronized能实现需求的情况下，优先考虑使用synchronized来进行同步。