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()这种方法来实现等待程序的执行(这是很愚蠢的一种行为),在这里只是作为一种演示,为了把逻辑比较清晰地表达出来。实际开发中通常是在成功执行一段程序,在获取预定的结果之后,再手动地释放锁。

 

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

 

那么如果我让进程2先开启呢?

 

结果如下:

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

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

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

posted @ 2018-08-21 22:04  2015夏  阅读(855)  评论(0编辑  收藏  举报