http://blog.csdn.net/dong976209075/article/details/8004325
理论上：
mutex和spinlock都是用于多进程/线程间访问公共资源时保持同步用的，只是在lock失败的时候处理方式有所不同。首先，当一个thread 给一个mutex上锁失败的时候，thread会进入sleep状态，从而让其他的thread运行，其中就包裹已经给mutex上锁成功的那个thread，被占用的lock一旦释放，就会去wake up 那个sleep的thread。其次，当一个thread给一个spinlock上锁失败的时候，thread会在spinlock上不停的轮讯，直到成功，所以他不会进入sleep状态（当然，时间片用完了，内核会自动进行调度）。
存在的问题：
无论是mutex还是spinlock，如果一个thread去给一个已经被其他thread占用的锁上锁，那么从此刻起到其他thread对此锁解锁的时间长短将会导致mutex和spinlock出现下面的问题。
mutex的问题是，它一旦上锁失败就会进入sleep，让其他thread运行，这就需要内核将thread切换到sleep状态，如果mutex又在很短的时间内被释放掉了，那么又需要将此thread再次唤醒，这需要消耗许多CPU指令和时间，这种消耗还不如让thread去轮讯。也就是说，其他thread解锁时间很短的话会导致CPU的资源浪费。
spinlock的问题是，和上面正好相反，如果其他thread解锁的时间很长的话，这种spinlock进行轮讯的方式将会浪费很多CPU资源。
解决方法：
对于single-core/single-CPU，spinlock将一直浪费CPU资源，如果采用mutex，反而可以立刻让其他的thread运行，可能去释放mutex lock。对于multi-core/mutil-CPU，会存在很多短时间被占用的lock，如果总是去让thread sleep，紧接着去wake up，这样会浪费很多CPU资源，从而降低了系统性能，所以应该尽量使用spinlock。
现实情况：
由于程序员不太可能确定每个运行程序的系统CPU和core的个数，所以也不可能去确定使用那一种lock。因此现在的操作系统通常不太区分mutex和spinlock了。实际上，大多数现代操作系统已经使用了混合mutex（hybrid mutex）和混合spinlock（hybrid spinlock）。说白了就是将两者的特点相结合。
hydrid mutex：在一个multi-core系统上，hybrid mutex首先像一个spinlock一样，当thread加锁失败的时候不会立即被设置成sleep，但是，当过了一定的时间（或则其他的策略）还没有获得lock，就会被设置成sleep，之后再被wake up。而在一个single-core系统上，hybrid mutex就不会表现出spinlock的特性，而是如果加锁失败就直接被设置成sleep。
hybrid spinlock：和hybrid mutex相似，只不过，thread加锁失败后在spinlock一段很短的时间后，会被stop而不是被设置成sleep，stop是正常的进程调度，应该会比先让thread sleep然后再wake up的开销小一些。
总结：
写程序的时候，如果对mutex和spinlock有任何疑惑，请选择使用mutex。
原文参考：http://stackoverflow.com/questions/5869825/when-should-one-use-a-spinlock-instead-of-mutex