互斥锁机制

锁机制，可以说是linux整个系统的精髓所在，linux内核都是围绕着同步在运转。在多进程和多线程编程中，锁起着极其重要的作用。我这里说的是互斥锁，其实是泛指linux中所有的锁机制。我在这里不讲如果创建锁，关于锁的创建，网上代码很多，我在这里就不多说了。我要谈一谈一个让所有刚刚接触锁机制的程序员都很困惑的问题：如何使用以及锁机制在程序中是如何运作的。

 

 

为什么要使用锁

这个就比较简单，linux里面，锁的种类很多，包括互斥锁，文件锁，读写锁······其实信号量说白了也是一种锁。使用锁的目的是达到同步的作用，使共享资源在同一时间内，只有能有一个进程或者线程对他进行操作。

 

 

linux是如何通过锁来实现对数据的保护和维护的

这个问题是我要将的重点。很多刚刚接触锁机制的程序员，都会犯这种错误。比如，此时有2个线程，分别是线程A，线程B。A和B共享了资源M。为了同步A和B，使得同一时刻，同意时刻，只有一个线程对M操作。于是，很自然的会在A中对M资源先lock，等到A对M操作完毕之后，然后做一个操作unlock。B中则因为A加了锁，B就直接操作M。这个时候，你会发现，B同样可以操作到M。这个是为什么呢？

 

我们利索当然的把检测锁的任务交给了操作系统，交给了内核。可以翻看APUE上对于所的讲解，其中一部分是这么写的：

 

This mutual-exclusion mechanism works only if we design our threads to follow the same data-access rules. The operating system doesn't serialize access to data for us. If we allow one thread to access a shared resource without first acquiring a lock, then inconsistencies can occur even though the rest of our threads do acquire the lock before attempting to access the shared resource.

 

这里This mutual-exclusion mechanism指的就是锁机制。说的很清楚，只有程序员设计线程的时候，都遵循同一种数据访问规则，锁机制才会起作用。操作系统不会为我们序列化数据访问，也就是说，操作系统不会为我们拟定任何数据访问顺序，到底是A在先还是B在先，操作系统不会为我们规定。如果我们允许一个线程在没有多的锁(lock)之前，就对共享数据进行访问操作，那么，即使我们其他的线程都在访问之前试图去先锁住资源(获取锁)，同样会导致数据访问不一致，即多个线程同时在操作共享资源。

    从上面文字可以看出，操作系统不会为我们去检查，此时是不是有线程已经把资源锁住了。为了使锁能够正常工作，为了保护共享资源，我们只有在设计线程的时候，所有线程都用同一种方法去访问共享数据，也就是访问数据之前，务必先获取锁，然后再操作，操作完之后要解锁(unlock)。操作系统提供锁机制，就是提供了一种所有程序员都必须遵循的规范。而不是说我们锁住资源，其他线程访问共享资源的时候，让操作系统去为我们检查数据是否有其他的线程在操作。