5

specifically, is the "+=" operation atomic? does it make a difference if i'm using the 'event' keyword, or just a plain old delegate?

with most types, its a read, then the "+" operator, and then a write. so, it's not atomic. i'd like to know if there's a special case for delegates/events.

is this kind of code necessary, or redundant:

Action handler;
object lockObj;
public event Action Handler {
    add { lock(lockObj) { handler += value; } }
    remove { lock(lockObj) { handler -= value; } }
}
notallama
  • 1,069
  • 1
  • 8
  • 11
  • possible duplicate of [Add delegate to event - thread safety](http://stackoverflow.com/questions/3522361/add-delegate-to-event-thread-safety) – StriplingWarrior Apr 02 '14 at 23:52

2 Answers2

4

Yes, the += and -= operators on auto implemented events are atomic (if a library used a custom event handler it could very easily not be atomic). From the MSDN Magazine article .NET Matters: Event Accessors

When the C# compiler generates code for MyClass, the output Microsoft® Intermediate Language (MSIL) is identical in behavior to what would have been produced using code like that in Figure 1.

Figure 1 Expanded Event Implementation

class MyClass
{
    private EventHandler _myEvent;

    public event EventHandler MyEvent
    {
        [MethodImpl(MethodImplOptions.Synchronized)]
        add 
        { 
            _myEvent = (EventHandler)Delegate.Combine(_myEvent, value);
        }
        [MethodImpl(MethodImplOptions.Synchronized)]
        remove 
        { 
            _myEvent = (EventHandler)Delegate.Remove(_myEvent, value); 
        }
    }
    ...
}

[...]

Another use for explicit event implementation is to provide a custom synchronization mechanism (or to remove one). You'll notice in Figure 1 that both the add and remove accessors are adorned with a MethodImplAttribute that specifies that the accessors should be synchronized. For instance events, this attribute is equivalent to wrapping the contents of each accessor with a lock on the current instance:

add { lock(this) _myEvent += value; } 
remove { lock(this) _myEvent -= value; }
Scott Chamberlain
  • 124,994
  • 33
  • 282
  • 431
  • +1, a great example of why to avoid locking on state objects like `lock (_eventSource) { ... }`. – noseratio Apr 03 '14 at 00:49
  • What about when calling `MyEvent?.Invoke(sender, EventArgs.Empty)` How is the backing InvocationList threadsafe? (which doesn't have access to your lock object) – Jeroen van Langen Nov 09 '21 at 13:09
  • The invokation list is immutable in that context. Once the Invoke is called it will call all handlers that where attached at point in time. – Scott Chamberlain Nov 12 '21 at 21:36
3

As noted here, the add handler is auto-implemented in a thread-safe way that will perform better than a lock.

What you need to be more careful of, when it comes to thread-safety on events, is how you invoke them. See Eric Lippert's post on this here.

The standard pattern for firing this event is:

Action temp = Foo;
if (temp != null)
      temp();
Community
  • 1
  • 1
StriplingWarrior
  • 151,543
  • 27
  • 246
  • 315