## 5.1.?scull 中的缺陷 讓我們快速看一段 scull 內存管理代碼. 在寫邏輯的深處, scull 必須決定它請求的內存是否已經分配. 處理這個任務的代碼是: ~~~ if (!dptr->data[s_pos]) { dptr->data[s_pos] = kmalloc(quantum, GFP_KERNEL); if (!dptr->data[s_pos]) goto out; } ~~~ 假設有 2 個進程( 我們會稱它們為"A"和"B" ) 獨立地試圖寫入同一個 schull 設備的相同偏移. 每個進程同時到達上面片段的第一行的 if 測試. 如果被測試的指針是 NULL, 每個進程都會決定分配內存, 并且每個都會復制結果指針給 dptr->datat[s_pos]. 因為 2 個進程都在賦值給同一個位置, 顯然只有一個賦值可以成功. 當然, 發生的是第 2 個完成賦值的進程將"勝出". 如果進程 A 先賦值, 它的賦值將被進程 B 覆蓋. 在此, scull 將完全忘記 A 分配的內存; 它只有指向 B 的內存的指針. A 所分配的指針, 因此, 將被丟掉并且不再返回給系統. 事情的這個順序是一個競爭情況的演示. 競爭情況是對共享數據的無控制存取的結果. 當錯誤的存取模式發生了, 產生了不希望的東西. 對于這里討論的競爭情況, 結果是內存泄漏. 這已經足夠壞了, 但是競爭情況常常導致系統崩潰和數據損壞. 程序員可能被誘惑而忽視競爭情況為相當低可能性的事件. 但是, 在計算機世界, 百萬分之一的事件會每隔幾秒發生, 并且后果會是嚴重的. 很快我們將去掉 scull 的競爭情況, 但是首先我們需要對并發做一個更普遍的回顧.