執行緒鎖 Lock

多執行緒和多程序最大的不同在於，多程序中，同一個變數，各自有一份拷貝存在於每個程序中，互不影響，而多執行緒中，所有變數都由所有執行緒共享，所以，任何一個變數都可以被任何一個執行緒修改，因此，執行緒之間共享資料最大的危險在於多個執行緒同時改一個變數，把內容給改亂了。

先看一個沒有加鎖的操作

balance = 0
def change_it_without_lock(n):
    global balance
    # 不加鎖的話 最後的值不是0
    # 執行緒共享資料危險在於 多個執行緒同時改同一個變數
    # 如果每個執行緒按順序執行，那麼值會是0， 但是執行緒時系統排程，又不確定性，交替進行
    # 沒鎖的話，同時修改變數
    # 所以加鎖是為了同時只有一個執行緒再修改，別的執行緒表一定不能改
    for i in range(100000):
        balance = balance + n
        balance = balance - n

    print balance

threads = [
    threading.Thread(target=change_it_without_lock, args=(8,) ),
    threading.Thread(target=change_it_without_lock, args=(10,) )
]

[t.start() for t in threads]
[t.join() for t in threads]

print balance
 

我們定義了一個共享變數balance，初始值為0，並且啟動兩個執行緒，先存後取，理論上結果應該為0
但是，由於執行緒的排程是由作業系統決定的，當t1、t2交替執行時，只要迴圈次數足夠多，balance的結果就不一定是0了。

按照一個執行緒的思想， balance無論處理迴圈多少次都是等於0的，然而開了2個執行緒最後結果卻不是0，那是因為兩個執行緒交換進行，操作沒有原子性，比如，
執行緒1進行到 balance=balance + 8 == 0 + 8 = 8
此時切換到執行緒2，執行緒2拿到的balance=8, 進行balance = 8 + 10 = 18，
此時切換到前程1 ，balance = balance - 8 = 18-8=10 ! = 0
執行緒1的結果已經不等0，之後的結果也會亂套，就是因為操作沒有原子性，
所以我們多執行緒操作同一個資源（這裡就是全域性變數balance）的時候，需要加鎖

加鎖修改後，程式碼

def change_it_with_lock(n):
    global balance
    if lock.acquire():
        try
            for i in range(100000):
                balance = balance + n
                balance = balance - n
        # 這裡的finally 防止中途出錯了，也能釋放鎖
        finally:
            lock.release()
threads = [
    threading.Thread(target=change_it_without_lock, args=(8,) ),
    threading.Thread(target=change_it_without_lock, args=(10,) )
]
lock = threading.Lock()
[t.start() for t in threads]
[t.join() for t in threads]

print balance
# 這裡的結果一定是0
 

執行緒死鎖

執行緒的一大問題就是通過加鎖來”搶奪“共享資源的時候有可能造成死鎖，例如下面的程式：

import threading
import os
import time
import random

balance=0
def change_it(n, lock):
    global balance
    threading_name = threading.currentThread().name
    if lock.acquire():
        try:
            for i in range(1000000):
                balance = balance + n
                balance = balance - n
                #time.sleep(random.random())
                # 中途錯誤，會死鎖，所以應該包個try finally 釋放鎖
                # 假設執行緒1中途錯誤， 沒有釋放鎖
                if i == 200 and threading_name == 'Thread-1':
                    print 'set error', threading_name
                    raise Exception('hah')

            #  迴圈完釋放鎖， 但是執行緒1來不到這裡 已經出錯了
            lock.release()
        except Exception, e:
            print 'error', threading_name
            pass
        finally:
            pass
            print 'release lock', threading_name
            print 'i is ',  i, threading_name
            # 這裡註釋了， 最安全的做法應該釋放鎖是放在這裡的， 我們為了演示死鎖，註釋掉
            #lock.release()
lock2 = threading.Lock()

t1 = threading.Thread(target=change_it, args=(5, lock2))
t2 = threading.Thread(target=change_it, args=(5, lock2))
t1.start()
t2.start()
t1.join()
t2.join()
print balance

還有一種死鎖不是由於內部錯誤，沒有合理釋放鎖導致的， 就是兩個執行緒都在等待對方的鎖，看下面程式碼：

from threading import Lock  
_base_lock = Lock()  
_pos_lock  = Lock()  
_base = 1

def _sum(x, y):  
    # Time 1
    with _base_lock:
        # Time 3
        with _pos_lock:
            result = x + y
    return result
def _minus(x, y):  
    # Time 0
    with _pos_lock:
        # Time 2
        with _base_lock:
            result = x - y
    return result

由於執行緒的排程執行順序是不確定的，在執行上面兩個執行緒 _sum/_minus
的時候就有可能出現註釋中所標註的時間順序，即 # Time 0
的時候執行到 with _pos_lock
獲取了_pos_lock 鎖，
而接下來由於阻塞馬上切換到了 _sum 中的 # Time 1，並獲取了_base_lock
，接下來由於兩個執行緒互相鎖定了彼此需要的下一個鎖，將會導致死鎖，即程式無法繼續執行。根據 我是一個執行緒 中所描述的，為了避免死鎖，需要所有的執行緒按照指定的演算法（或優先順序）來進行加鎖操作。不管怎麼說，死鎖問題都是一件非常傷腦筋的事，原因之一在於不管執行緒實現的是併發還是並行，在程式設計模型和語法上看起來都是並行的，而我們的大腦雖然是一個（內隱的）絕對並行加工的機器，卻非常不善於將並行過程具象化（至少在未經足夠訓練的時候）。而與執行緒相比，協程（尤其是結合事件迴圈）無論在程式設計模型還是語法上，看起來都是非常友好的單執行緒同步過程。