python同步原语--线程锁

多线程锁是python多种同步原语中的其中一种。首先解析一下什么是同步原语，python因为GIL（全局解析锁）的缘故，并没有真正的多线性。另外python的多线程存在一个问题，在多线程编程时，会出现线程同时调用共同的存储空间而导致错误的出现（即‘竞态行为’）。虽然许多专家建议python开发者在处理并发的时候弃用多线程而用多进程，但是在I/O操作这种短时间的操作上（通常GIL锁在这段时间内已经释放），多线程编程还是有很大的优势的。而在计算密集型的编程时，本人还是觉得用多进程比较稳妥。

在处理多线程的‘竞态行为’的问题上，python提供了不少解决的方法--同步原语，例如：锁，事件，信号量等。

所以问题回归到锁添加的原因和加锁的优势：

在多线程同时进入临界资源区获取和操作共有资源时，会出现资源的争夺而出现混乱。为了避免这种混乱现象，python提出了锁机制，能够实现多线程程序的同步执行，从而避免因争夺资源而出现错误。

线程锁的定义和运用

一、创建锁对象：

语法：

lock = Lock()

锁对象一旦创建，就可以随时被进程或者线程调用，并且一次创建锁只有一把，如果多个资源想同时获取锁，必须‘排队’，等上一个进程/线程释放了锁才可以请求获取锁

二、上锁（也叫请求锁）

语法：

lock.acquire()

acquire()是一个阻塞函数。一旦请求获取锁成功，就会把下面将要执行的程序的变量内存空间‘锁住’；而获取不成功则会一直阻塞在那里，等待上一个获得锁的进程/线程

释放锁。

三、解锁

lock.release()

锁的创建、获取和释放其实很简单，而在实际运用中还需要处理一些比较复杂的问题。下面谈谈死锁的问题。

死锁和可重入锁

死锁的出现有两种情况：

1) 当一个进程或者一个线程一直调用或者占用同一锁Lock而不释放资源而导致其他进程/线程无法获得锁，就会出现的死锁状况，一直阻塞在aquire()处

2) 当有两个线程同时想获取两个锁的时候（再往上推就是多个线程想获取多个锁甚至是一个线程想获取多个锁），例如递归函数（一个线程获取多个锁）的使用。由于两者都是处于竞争关系，谁也不让谁，谁快谁得手，但计算机中这种竞争关系是很微妙的，时间的差异性很小，于是，就出现了两者都阻塞在同一个地方，都无法同时获得两个锁或者获取对方已经获取的但还没有释放的锁。

为了解决死锁的问题，于是python提出了可重入锁的机制(RLock)

重入锁定义后，一个进程就可以重复调用指定次数的一个重入锁，而不用去跟别的进程一起争夺其他锁。

重入锁中内部管理者两个对象，即Lock对象和锁的调用次数count

下面说说RLock到底是怎么用的

1）RLock的定义

mutexA = mutexB = RLock( )

mutex值可以是多个的，定义了多少个，RLock内部的count就为几

2）RLock的请求

mutexA.acquire()
mutexA.acquire()

上面这两行代码看似是一样的，但其实是两次请求锁。每申请一次锁，Rlock内部的count就会减小1，两次请求过后，count从2减为0

因为上面定义的重入锁的内部个数为2，所以该重入锁可以被一个进程调用两次，并且在虽然它内部有多个锁，但只能由一个进程/线程调用，其他进程/线程不能干预，只有当这个进程/线程释放掉所有的重入锁，count重新变为count=2时才可以被其他进程/线程调用。

3）RLock锁的释放

mutexA.release()
mutexB.release()

完整代码举例：

from multiprocessing import RLock,Process
from time import ctime,sleep

mutexA = mutexB =RLock()     #定义可重入锁，内部有两个锁，即mutexA和mutexB

def fn1():
    mutexA.acquire()
    sleep(1)
    print(ctime(),'进程1获取A锁')
    mutexB.acquire()
    sleep(2)
    print(ctime(),'进程1获取B锁')
    mutexA.release()
    print('进程1释放A锁')
    mutexB.release()
    print('进程1释放B锁')

def fn2():
    mutexA.acquire()
    sleep(1)
    print(ctime(),'进程2获取A锁')
    mutexB.acquire()
    sleep(1)
    print(ctime(),'进程2获取B锁')
    mutexA.release()
    print('进程2释放A锁')
    mutexB.release()
    print('进程2释放B锁')

p1 = Process(target=fn1)   #定义进程1
p2 = Process(target=fn2)   #定义进程2
p1.start()       #开启进程1
p2.start()       #开启进程2

p1.join()        #回收进程空间
p2.join()

注意：在实际开发中我们当然不会用sleep()这种方法来实现等待程序的执行（这是很愚蠢的一种行为），在这里只是作为一种演示，为了把逻辑比较清晰地表达出来。实际开发中通常是在成功执行一段程序，在获取预定的结果之后，再手动地释放锁。

那么上面的程序运行结果如下：

那么如果我让进程２先开启呢？

结果如下：

第一个案例中因为p1的进程比p2的进程更早运行（程序在运行顺序上更早），所以p1先获取了可重入锁。而在案例2中，p2就比p1更早地获取可重入锁了。

显然，从这两个案例中我们发现，锁的获得是谁快谁得手。同时也验证了我上面描述的，一个进程对一个可重入锁的请求是排他型的，一旦这个进程请求了

一个可重入锁，那么其他进程就无法再请求了，直到这个进程释放了可重入锁内部的所有锁。