Internal design of event in C#

Question

Just finished reading Jon Skeet's article about events and delegates and got a question.

Lets say first in the code I declare an event

public event EventHandler MyEvent

Then I want to raise it in the code in a manner

if (MyEvent != null)
    Myevent(this,EvtArgs.Empty);

Jon says that in fact MyEvent looks somehow like this:

private EventHandler _myEvent;

public event EventHandler MyEvent
{
    add
    {
        lock (this)
        {
            _myEvent += value;
        }
    }
    remove
    {
        lock (this)
        {
            _myEvent -= value;
        }
    }        
}

The question is what really happens when I compare MyEvent != null ? As I understand in fact it compares _myEvent to null, but I am not sure.

That is my understanding also, hopefully the great man will come in and enlighten us :) — krystan honour, Apr 02 '12 at 12:17

score 5 · Accepted Answer · answered Apr 02 '12 at 12:18

If you implement custom add/remove accessors, you won't be able to compare MyEvent to null in the first place, because it will only be an event - it doesn't have a value as such, only add/remove accessors. You would have to use your declared field (_myEvent in the sample above) instead.

You can only do the comparison using the event name when you're using field-like events, where you end up with (effectively) a field and an event with the same name. (The compiled code doesn't have to actually reuse the event name for the field name, but it has to look like it does when you're compiling.)

Note that using this:

if (MyEvent != null)
    MyEvent(this,EvtArgs.Empty);

isn't thread-safe, as MyEvent could become null between the check and the invocation. You should use:

EventHandler handler = MyEvent;
if (handler != null)
{
    handler(this, EventArgs.Empty);
}

Also note that the part about field-like events locking on this is now slightly outdated; in C# 4 thread-safety is achieved using a lock-free compare-exchange mechanism.

That isn't thread safe either. This way you can call a handler of a disposed class. — huysentruitw, Apr 02 '12 at 12:21
@WouterH: Potentially. That race condition is unavoidable though, unless you lock for the duration of the invocation - whereas the race condition in the question *is* avoidable. — Jon Skeet, Apr 02 '12 at 12:23

score 1 · Answer 2 · answered Apr 02 '12 at 12:17

1

When there is no handler subscribed to MyEvent, MyEvent will equal null. So before firing the event, you first check if there is at least one handler subscribed to it.

answered Apr 02 '12 at 12:17

huysentruitw

27,376
9
90
133

score 1 · Answer 3 · edited May 23 '17 at 12:04

1

Internally an event is a set of add/remove methods with a backing field of type MulticastDelegate You get this field when you are asking for MyEvent outside of the class and compare this instance to null.

See also this post: How do C# Events work behind the scenes?

Edit: Also, as pointed out by Jon already, you don't get a field in case you provide the add/remove methods yourself.

edited May 23 '17 at 12:04

Community

1
1

answered Apr 02 '12 at 12:18

aKzenT

7,775
2
36
65

1

No, an event is just an add/remove pair. A *field-like event* consists of an event *and* a backing field (of the event type). The code compares the value of that field with null. – Jon Skeet Apr 02 '12 at 12:20
Further clarification - there's no *requirement* for a backing field at all. It's like a property - what you do is up to you, but *typically* there will be a backing field (of the event type, not just bare MulticastDelegate). – Jon Skeet Apr 02 '12 at 12:46

Internal design of event in C#

3 Answers3