突然想到有關C#中使用event特性時關于線程安全的問題，以前雖然有遵從“復制引用+null判斷”的模式（盲目地），但沒有深入了解和思考。

為之查詢了資料和實驗，對此有了進一步的理解。

一般event使用模式

定義（field-like event）：

public event EventHandler Done;

類內raise：

PRotected void OnDone(){    var done = Done;    if (done != null)    {        done(this, new EventArgs());    }}

不禁要問，為何要復制引用？多線程下表現如何？

關于C#3.0和C#4.0中編譯器對event實現的整理

為了解決上面哪些疑惑，我查了一些資料，其中有來自當時C#編譯器開發組成員的一篇博文 Field-like Events Considered Harmful。

這篇博文介紹了C#3.0中編譯器對于field-like event（也是最常見的使用方式）的實現。

對于如此的代碼，

class EventInCS3{    public event EventHandler Done;}

編譯器會將其轉換成：

class EventInCS3{    private EventHandler __Done; // 1    public event EventHandler Done    {        add        {            lock (this) // 2            {                __Done = __Done + value; // 3            }        }        remove        {            lock (this) { __Done = __Done - value; }        }    }}

有以下幾點值得注意（同注釋編號）：

1.event下隱藏的真正delegate鏈。實際上我們使用的是子類MulticastDelegate（可以參考 開源的coreclr實現）。

3.正如+、-操作符對于string類型是起字符串組合作用，其對于delegate類型也同樣是起到兩條鏈的組合作用（參考 MSDN），實際上是調用了Delegate.Combine和Delegate.Remove。同時也引入了經典的線程問題（修改丟失）。

2.為了解決多線程問題，使用了lock。

（就先不管這個lock(this)了。當然上面提到的 博文 里提到了，編譯器并不是通過lock，繼而通過Monitor的靜態方法來同步，而是通過IL即MethodImplAttribute(MethodImplOptions.Synchronized)實現。這些都是C#本身不推薦的方法。）

而在C#4.0中，同步的實現有了變化，同樣參見同一作者兩年后的 這一篇博文。

編譯器默認的add、remove實現，改為使用compare and swap來實現lock-free同步。值得注意的是，delegate是不可更改的類型，即+=、-=之后，會指向一個新的對象，而不再是原對象（類似string）。

通過IL查看程序集里生成的add_Done、remove_Done，可以發現端倪，大致會生成如下的代碼：

static void add_Done(EventHandler value){    EventHandler V_0 = __Done;    EventHandler V_1, V_2;    do    {        V_1 = V_0;        V_2 = (EventHandler)Delegate.Combine(V_1, value);        V_0 = Interlocked.CompareExchange<EventHandler>(ref __Done, V_2, V_1);    } while (V_0 != V_1);}

C#4.0中event相關的語義變化整理

在同一作者的 另一篇博文 中，介紹了C#4.0中event相關的語義變化，主要是+=、-=操作符的語義變化。

在C#3.0中，對于一個event，如果在該類之外訪問這個event，則會被認為是訪問這個event本身，如我們熟知的只能通過+=、-=這兩個操作符來訪問（即是調用對應的add、remove訪問器）；而在類的內部，所有對這個event的訪問，都會被認為是訪問作為event實現的delegate本身（即訪問Done，實際上訪問到的是__Done）。

這么處理的話，我們就能在OnDone方法里復制引用，判斷null，進行調用。因為此時Done這個標識符，代表的是一個EventHandler對象的引用。

C#3.0的問題也在于此，這種情況下，我們寫下

Done += SomeHandlerMethod;

時，+=實際是調用了：

EventHandler EventHandler.Operator +(EventHandler left, EventHandler right)

在Visual Studio 2015里寫一個普通的、非event的EventHandler的+=運算，鼠標放在+=上時，顯示的也是這個函數簽名。C#3.0時即使對event也是這么處理的。

導致我們失去了默認add訪問器提供的同步功能。

而這一現象在C#4.0中得到了改善。在類內部訪問event的標識符時，+=、-=操作符就會被認為是add、remove的調用了。

可知在C#4.0寫下同樣的代碼時，+=調用的簽名為：

void EventInCS4.Done.add 

自定義event訪問器

自定義event時（非field-like event），我們自己編寫的add、remove訪問器就沒有默認的同步了。如果要考慮線程安全，需要手動加上同步（比如lock(someLockObject)）。

此時，在類內部訪問event標識符，只會被當成是訪問event本身。要引發事件（Done）的話，需訪問對應delegate（__Done(this, new EventArgs())）。

操作event的正確方式

一般情況下無需自己實現event，用field-like就好了。

因為不管是通過event標識符訪問delegate（field-like event），還是直接訪問delegate（自定義event），我們得到的都是delegate對象的引用，而且delegate對象是不可更改的。引用的復制是原子的。所以我們可以隨意地復制該delegate的引用，然后判斷null并invoke。

一些code snippet如：

1. 通過擴展方法來引發事件：

   public static class EventExtension{    public static void Raise<T>(this EventHandler<T> handler, object sender, T args)    {        if (handler != null)        {            handler(sender, args);        }    }    public static void Raise(this EventHandler handler, object sender, EventArgs args); // 重載版}

   delegate的引用會以pass-by-value形式得到復制，所以直接

   Done.Raise(this, new EventArgs());

2.  通過C#6.0提供的Null-conditional操作符：

   Done?.Invoke(this, new EventArgs());

   null-conditional操作符也會進行引用的復制，所以是線程安全的。（沒有Done?(...)這種寫法）

附

對于編譯器是否會將復制引用作為重復的局部變量優化掉，以至于在一些情況下需要使用諸如以下的方式的問題，我沒有深入了解。

Interlocked.CompareExchange(ref Done, null, null);

簡單查詢一下之后，得知對于微軟自家的CLR無需關心這個問題，蓋其遵循較嚴格的內存模型（memory model），不會引入新的讀取操作。但其他情況下有可能存在這樣的問題。相關文章和討論鏈接如下：

1. http://stackoverflow.com/questions/11159176/thread-safe-event-calls
2. http://code.logos.com/blog/2008/11/events_and_threads_part_4.html
3. Understand the Impact of Low-Lock Techniques in Multithreaded Apps MSDN Magazine Oct 2005 （需要下載chm看）