编码事件访问器时的多线程问题

Question

I'm looking for additional information about why Microsoft recommends locking on the object when coding event accessor syntax. Microsoft's code example is shown below and the recommendation is linked to.

I understand the general concept about locking over a section of code to control multi-threaded access to it, however I'm looking for the specific reason why those concerns come into play when coding custom event accessor logic in context of Microsoft's example shown.

The following example shows how to implement custom add and remove event accessors. Although you can substitute any code inside the accessors, we recommend that you lock the event before you add or remove a new event handler method.

event EventHandler IDrawingObject.OnDraw
    {
        add
        {
            lock (PreDrawEvent)
            {
                PreDrawEvent += value;
            }
        }
        remove
        {
            lock (PreDrawEvent)
            {
                PreDrawEvent -= value;
            }
        }
    }

~ via https://msdn.microsoft.com/en-us/library/bb882534.aspx?f=255&MSPPError=-2147217396

Answer 1

Only the author of the MSDN article can provide you a definitive answer as to the wording of the article.

However: it seems to me that the primary reason for the advice is that code almost always uses the compiler-provided event accessor methods. These have always been intended to be 100% thread safe, and with a recent change in the compiler (I think as of C# 4, but I don't recall for sure), they actually are.

The reasons for making the default implementation thread-safe is, I think, self-explanatory: doing so involves reasonably low cost, and the need for thread-safety in event accessor methods is frequent enough that forcing developers to implement their own accessors every time they need thread safety would be unreasonable.

So, given that the default implementation is thread-safe, this means that consumers of events (who often will not have ready access to the source code of the event) are going to be in the habit of assuming that event accessors are always thread-safe. Violating this assumption can lead to code with bugs in it.

Bottom line: if you are 100% sure your event will only ever be accessed in a single thread, or at least in a thread-safe way, you can get away without adding explicit thread-safety to the accessor methods. The problem is that arriving at this 100% certainty is of dubious validity; it's nearly impossible to predict how a particular piece of code will be used, especially the farther into the future one is talking about.

Code can live for a surprisingly long time. Best to make sure it can handle what's thrown at it, and especially when future clients of the code have every reason to assume the code can handle it.

As an aside: while the MSDN shows locking on the event field itself, this seems problematic to me. The moment the field has been updated, any currently held lock is going to not prevent subsequently executing code from entering the lock, even if the lock itself hasn't been exited. There could be field visibility issues on some platforms, due to misordering of reads and writes to the field; this could lead to two subsequently executing threads seeing different values for the lock, and then entering the protected section concurrently.

Never mind the more general problem of using publicly available values for locking. There is some debate on that particular topic, but it is my preference to only ever use private values for locking. Ie don't lock using the event field's current value (because it's changeable) and don't lock using this (because it's public).