Python讀寫鎖實(shí)現(xiàn)實(shí)現(xiàn)代碼解析
起步
Python 提供的多線程模型中并沒有提供讀寫鎖,讀寫鎖相對于單純的互斥鎖,適用性更高,可以多個(gè)線程同時(shí)占用讀模式的讀寫鎖,但是只能一個(gè)線程占用寫模式的讀寫鎖。
通俗點(diǎn)說就是當(dāng)沒有寫鎖時(shí),就可以加讀鎖且任意線程可以同時(shí)加;而寫鎖只能有一個(gè)線程,且必須在沒有讀鎖時(shí)才能加上。
簡單的實(shí)現(xiàn)
import threading
class RWlock(object):
def __init__(self):
self._lock = threading.Lock()
self._extra = threading.Lock()
self.read_num = 0
def read_acquire(self):
with self._extra:
self.read_num += 1
if self.read_num == 1:
self._lock.acquire()
def read_release(self):
with self._extra:
self.read_num -= 1
if self.read_num == 0:
self._lock.release()
def write_acquire(self):
self._lock.acquire()
def write_release(self):
self._lock.release()
這是讀寫鎖的一個(gè)簡單的實(shí)現(xiàn),self.read_num 用來保存獲得讀鎖的線程數(shù),這個(gè)屬性屬于臨界區(qū),對其操作也要加鎖,所以這里需要一個(gè)保護(hù)內(nèi)部數(shù)據(jù)的額外的鎖 self._extra 。
但是這個(gè)鎖是不公平的。理想情況下,線程獲得所的機(jī)會應(yīng)該是一樣的,不管線程是讀操作還是寫操作。而從上述代碼可以看到,讀請求都會立即設(shè)置 self.read_num += 1,不管有沒有獲得鎖,而寫請求想要獲得鎖還得等待 read_num 為 0 。
所以這個(gè)就造成了只有鎖沒有被占用或者沒有讀請求時(shí),可以獲得寫權(quán)限。我們應(yīng)該想辦法避免讀模式鎖長期占用。
讀寫鎖的優(yōu)先級
讀寫鎖也有分 讀優(yōu)先 和 寫優(yōu)先。上面的代碼就屬于讀優(yōu)先。
如果要改成寫優(yōu)先,那就換成去記錄寫線程的引用計(jì)數(shù),讀和寫在同時(shí)競爭時(shí),可以讓寫線程增加寫的計(jì)數(shù),這樣可使讀線程的讀鎖一直獲取不到, 因?yàn)樽x線程要先判斷寫的引用計(jì)數(shù),若不為0,則等待其為 0,然后進(jìn)行讀。這部分代碼不羅列了。
但這樣顯然不夠靈活。我們不需要兩個(gè)相似的讀寫鎖類。我們希望重構(gòu)我們代碼,使它更強(qiáng)大。
改進(jìn)
為了能夠滿足自定義優(yōu)先級的讀寫鎖,要記錄等待的讀寫線程數(shù),并且需要兩個(gè)條件 threading.Condition 用來處理哪方優(yōu)先的通知。計(jì)數(shù)引用可以擴(kuò)大語義:正數(shù):表示正在讀操作的線程數(shù),負(fù)數(shù):表示正在寫操作的線程數(shù)(最多-1)
在獲取讀操作時(shí),先然后判斷時(shí)候有等待的寫線程,沒有,進(jìn)行讀操作,有,則等待讀的計(jì)數(shù)加 1 后等待 Condition 通知;等待讀的計(jì)數(shù)減 1,計(jì)數(shù)引用加 1,繼續(xù)讀操作,若條件不成立,循環(huán)等待;
在獲取寫操作時(shí),若鎖沒有被占用,引用計(jì)數(shù)減 1,若被占用,等待寫線程數(shù)加 1,等待寫條件 Condition 的通知。
讀模式和寫模式的釋放都是一樣,需要根據(jù)判斷去通知對應(yīng)的 Condition:
class RWLock(object):
def __init__(self):
self.lock = threading.Lock()
self.rcond = threading.Condition(self.lock)
self.wcond = threading.Condition(self.lock)
self.read_waiter = 0 # 等待獲取讀鎖的線程數(shù)
self.write_waiter = 0 # 等待獲取寫鎖的線程數(shù)
self.state = 0 # 正數(shù):表示正在讀操作的線程數(shù) 負(fù)數(shù):表示正在寫操作的線程數(shù)(最多-1)
self.owners = [] # 正在操作的線程id集合
self.write_first = True # 默認(rèn)寫優(yōu)先,F(xiàn)alse表示讀優(yōu)先
def write_acquire(self, blocking=True):
# 獲取寫鎖只有當(dāng)
me = threading.get_ident()
with self.lock:
while not self._write_acquire(me):
if not blocking:
return False
self.write_waiter += 1
self.wcond.wait()
self.write_waiter -= 1
return True
def _write_acquire(self, me):
# 獲取寫鎖只有當(dāng)鎖沒人占用,或者當(dāng)前線程已經(jīng)占用
if self.state == 0 or (self.state < 0 and me in self.owners):
self.state -= 1
self.owners.append(me)
return True
if self.state > 0 and me in self.owners:
raise RuntimeError('cannot recursively wrlock a rdlocked lock')
return False
def read_acquire(self, blocking=True):
me = threading.get_ident()
with self.lock:
while not self._read_acquire(me):
if not blocking:
return False
self.read_waiter += 1
self.rcond.wait()
self.read_waiter -= 1
return True
def _read_acquire(self, me):
if self.state < 0:
# 如果鎖被寫鎖占用
return False
if not self.write_waiter:
ok = True
else:
ok = me in self.owners
if ok or not self.write_first:
self.state += 1
self.owners.append(me)
return True
return False
def unlock(self):
me = threading.get_ident()
with self.lock:
try:
self.owners.remove(me)
except ValueError:
raise RuntimeError('cannot release un-acquired lock')
if self.state > 0:
self.state -= 1
else:
self.state += 1
if not self.state:
if self.write_waiter and self.write_first: # 如果有寫操作在等待(默認(rèn)寫優(yōu)先)
self.wcond.notify()
elif self.read_waiter:
self.rcond.notify_all()
elif self.write_waiter:
self.wcond.notify()
read_release = unlock
write_release = unlock
以上就是本文的全部內(nèi)容,希望對大家的學(xué)習(xí)有所幫助,也希望大家多多支持腳本之家。
相關(guān)文章
python中multiprosessing模塊的Pool類中的apply函數(shù)和apply_async函數(shù)的區(qū)別
這篇文章主要介紹了python中multiprosessing模塊的Pool類中的apply函數(shù)和apply_async函數(shù)的區(qū)別、文章圍繞主題的相關(guān)內(nèi)容展開詳細(xì)介紹,具有一定的參考價(jià)值,需要的小伙伴可以參考一下2022-06-06
用Python實(shí)現(xiàn)一個(gè)簡單的能夠發(fā)送帶附件的郵件程序的教程
這篇文章主要介紹了用Python實(shí)現(xiàn)一個(gè)簡單的能夠發(fā)送帶附件的郵件程序的教程,用MIMEApplication模塊來發(fā)送各種類型的文件,需要的朋友可以參考下2015-04-04

