Suppose you create a class like this one:

using System;

class C
{
    public event EventHandler E;

    public void AddHandler()
    {
        E += Handler; // thread-safe?
    }

    public void Handler(object sender, EventArgs e)
    {
    }
}

Is the statement in AddHandler thread-safe? I had heard that event accessors were thread-safe, but the truth is actually a bit more complicated. To find the answer, let's look at the code that actually gets generated for this class (or at least a C# rendering of the generated IL):

using System;
using System.Runtime.CompilerServices;

class C
{
    private EventHandler E;

    [MethodImpl(MethodImplOptions.Synchronized)]
    public void add_E(EventHandler handler)
    {
        E = (EventHandler)Delegate.Combine(E, handler);
    }

    [MethodImpl(MethodImplOptions.Synchronized)]
    public void remove_E(EventHandler handler)
    {
        E = (EventHandler)Delegate.Remove(E, handler);
    }

    public void AddHandler()
    {
        E = (EventHandler)Delegate.Combine(E, Handler);
    }

    public void Handler(object sender, EventArgs e)
    {
    }
}

Two things are interesting about this generated code: 1) The add and remove accessors used by event consumers outside the class are Synchronized to provide thread safety, as explained in section 10.8.1 of the C# Language Specification 3.0. 2) The AddHandler method uses the private delegate field rather than the add accessor, and therefore is not thread-safe. This second point is rather subtle, and is something I was only recently made aware of by an elusive threading bug in my code. (The C# language spec does mention this special case near the end of section 10.8.1: "Within the class X [which defines Ev], references to Ev are compiled to reference the hidden field __Ev instead".) AddHandler can be made thread-safe (with respect to itself and the generated accessors) by locking this:

    public void AddHandler()
    {
        lock (this)
        {
            E += Handler;
        }
    }

Incidentally, the "equivalent" code above is not entirely equivalent to the original code, in that it does not actually expose an event E that consumers can access using the += and -= operators. The closest you can get to equivalent source code is the following, which differs only from the compiler-generated code in that the compiler can name both the field and the event "E":

using System;
using System.Runtime.CompilerServices;

class C
{
    private EventHandler e;
    public event EventHandler E
    {
        [MethodImpl(MethodImplOptions.Synchronized)]
        add // generates 'public void add_E(EventHandler)'
        {
            e = (EventHandler)Delegate.Combine(e, value);
        }

        [MethodImpl(MethodImplOptions.Synchronized)]
        remove // generates 'public void remove_E(EventHandler)'
        {
            e = (EventHandler)Delegate.Remove(e, value);
        }
    }

    public void AddHandler()
    {
        e += Handler; // generates e = (EventHandler)Delegate.Combine(e, Handler);
    }

    public void Handler(object sender, EventArgs e)
    {
    }
}

It's also interesting to note that if the AddHandler method was changed to use "E += Handler" instead of "e += Handler", the compiler would call add_E instead (since events with user-provided accessors are not "field-like events," as defined in the language spec).

public interface I
{
    event EventHandler Important;
    event EventHandler Unimportant;
}

Forgetting about "unimportant" details, you'd probably start your implementation like this:

public class C : I
{
    public event EventHandler Important;
  
    protected virtual void OnImportant(EventArgs e)
    {
        EventHandler handler = this.Important;
        if (handler != null)
        {
            handler(this, e);
        }
    }
}

Of course, if you compile at this point, you'll get an error like this:

error CS0535: 'C' does not implement interface member 'I.Unimportant'

Obviously you need to define an implementation for Unimportant, even if you don't use it. Fortunately, it is very easy to implement an event:

public event EventHandler Unimportant;

The problem with this implementation is that, since it is not ever used, and yet has a non-trivial compiler-generated implementation (which tracks the list of active handlers), the compiler issues the following warning:

warning CS0067: The event 'C.Unimportant' is never used

The advice given by the compiler documentation isn't very helpful in this case; it just says you need to use the event. Other than creating a bogus reference to the event (or using '#pragma warning disable 67' to disable the warning), what does the compiler expect us to do? The right answer is to be explicit about what you expect from the event, which in this case, is nothing:

public event EventHandler Unimportant
{
    add { }
    remove { }
}

This will cleanly suppress the warning, as well as the extra compiler-generated implementation of a normal event. And as another added benefit, it prompts one to think about whether this do-nothing implementation is really the best implementation. For instance, if the event isn't so much unimportant as it is unsupported, such that clients that do rely on the functionality are likely to fail without it, it might be better to explicitly indicate the lack of support and fail fast by throwing an exception:

public event EventHandler Unsupported
{
    add { throw new NotSupportedException(); }
    remove { }
}

Of course, an interface that can be usefully implemented without some parts of its functionality is sometimes an indication that the interface is not optimally cohesive and should be split into separate interfaces.

-Trevor Robinson