多線程環(huán)境下，程序真是危機(jī)四伏
你管這也叫線程安全?
最近大意了，竟然想將《面試官：實(shí)現(xiàn)一個(gè)帶值變更通知能力的Dictionary》一文中的臨界鎖只應(yīng)用到寫操作。
內(nèi)心旁白：讀操作又不會(huì)修改數(shù)據(jù)，無論是新值還是舊值，反正能讀到。
不過我又快速清醒了，臨界鎖還真就得這么加。臨界鎖的目的是保證這一段代碼邏輯不會(huì)被打斷。
假如只應(yīng)用寫鎖：
某線程執(zhí)行到寫鎖前(剛觸發(fā)了一次變通通知)，這時(shí)cpu時(shí)間片輪轉(zhuǎn)或搶占， 切換到另外的線程又把這段代碼執(zhí)行了一次(因?yàn)樽值鋕ey-value還沒被前線程覆寫)，這樣一次value變更實(shí)際執(zhí)行了兩次變更操作，這就悲劇了。
結(jié)合之前《你管這叫線程安全?》一文中多線程對于i++、i--帶來的線程不安全的理解。
你品你細(xì)品：
本次線程安全是在宏觀代碼行執(zhí)行層面， 上次的i++ 是在微觀寄存器層面，歸根到底讓多線程在多核環(huán)境下：代碼邏輯不能被打斷(代碼執(zhí)行節(jié)奏可能被打斷)。
多線程環(huán)境下，程序運(yùn)行真是危機(jī)四伏。
微軟官方怎么說?
還沒完， 我還從微軟官方原子操作[1]找到一段話：
Reads and writes of the following data types are atomic: bool, char, byte, sbyte, short, ushort, uint, int, float, and reference types. In addition, reads and writes of enum types with an underlying type in the previous list are also atomic. Reads and writes of other types, including long, ulong, double, and decimal, as well as user-defined types, are not guaranteed to be atomic. Aside from the library functions designed for that purpose, there is no guarantee of atomic read-modify-write, such as in the case of increment or decrement.
直譯起來：
① bool char byte sbyte uint int float 和引用類型上的讀寫是原子操作;
② 由以上類型定義的枚舉類型操作也是原子類型;
③ long ulong double decimal和用戶定義類型上的讀寫不保證是原子操作;
④ 除了庫文件本身設(shè)計(jì)了線程安全，一般況下下都不保證讀寫是原子操作， 這也包括i++、i--
這段文字是不是刷新了某些童靴的認(rèn)知(包括在下)：
1. 以后使用long num=8888;時(shí)要留個(gè)心眼，你也許會(huì)讀到long類型的部分字節(jié)。
2.直譯第①點(diǎn)說引用類型的讀寫是原子操作，第③點(diǎn)說用戶類型不保證原子操作，但是大部分的用戶類型是引用類型，這不互相矛盾了嗎?
我向微軟官方提出了我的這個(gè)疑問，有興趣可以關(guān)注這個(gè)github issue[2]。
說說我的看法：
直譯第①點(diǎn)中說int，引用類型等讀寫操作是原子操作：應(yīng)該想表達(dá)的是純粹的賦值操作， 比如
- int a =1; // 賦值：線程安全
- Student s = new Student {}; // 引用賦值：線程安全
- Student s2= s; // 引用賦值：線程安全
針對引用類型Dictionary的其他操作自然不是線程安全的。
依據(jù)這個(gè)思路， 第①③點(diǎn)就不矛盾了。
That's All, 本文依舊是#線程安全#、#鎖# 這兩個(gè)老生常談的概念的延續(xù)， 我的知識體系也是在不斷迭代更新，不斷精煉。
