You sort of do.

First, keep in mind that when an event is raised in O1, even though O2  
normally runs in T2, its event handlers are executed on T1, where O1  
raised the event.  You probably already knew that, but just want to  
clarify.

Now, that means you do have the potential of having O2 running on T2  
unsubscribing at the same time that O1 running on T1 raises the event.  
There's a lot of event-based code out there that doesn't handle this  
situation, and usually it's okay because everything is actually running on  
the same thread.  But when the potential for this condition exists, at a  
minimum you need to do something like this:

    OnRaiseEvent(...)
    {
        EventType eventInstance = _eventField;

        if (eventInstance != null)
        {
            eventInstance(...);
        }
    }

This copies the event member field to the local variable eventInstance so  
that if the member field is set to null between the time it's checked for  
null and the time it's actually used, that's not an issue.  By copying it,  
you ensure that what's checked for null is your local variable, not the  
member field that could change.

Now, there is the separate issue of O2 having unsubscribed while O1 now  
has a reference to it in its local variable.  This means that even though  
O2 has unsubscribed, it's not quite done yet.  O1 still has a reference to  
O2, via the local variable, and O2 will still be called when the event  
variable is executed.

Whether this is a problem depends a lot on the design of O2 (and even of  
O1 to some extent).  In particular, if O2 can still respond to an event,  
even though you have discarded it somewhere else, then there's really no  
problem.  On the other hand, if you have a situation where O2 is  
disposable, and as part of disposing that's where you unsubscribe, and  
something else that is released as part of disposing is required in order  
to handle the event (get all that? :) ), then yes...you need to be able to  
sychronize access to the thing that is required, and in the event handler  
make an explicit check to verify that your object is in fact still in a  
state in which it can handle the event.  If it's not, then you would just  
ignore the event as it if never happened.

Once the O1 event raising method returns, the value in the local variable  
is released, and since the O1 instance member containing the event  
reference no longer refers to O2 either, you can at that point be assured  
the event handler will not be called again.  But you do need to be able to  
handle correctly the transient condition in which you think you've  
unsubscribed but could still get one more raised event.

Pete

O2 doesn't "catch" events at all. When O1 raises an event, if O2 has a
delegate in the handler list of the event, then the handler in O2 will be
called in thread T1.

You should do, yes - at least if you foresee people subscribing to or
unsubscribing from the events from a different thread.

See http://pobox.com/~skeet/csharp/threads/lockchoice.shtml