SharePoint usually fires two different events for each operation: a "before" event which fires before the operation has been performed and an "after" event which fires after the operation has been performed.
The before event is always raised on the same thread as the operation itself and allows to modify the operation to be performed or even to cancel it.
In SharePoint 2007 the after event was always asynchronous and fired on a separate thread as it allowed to perform some post processing work after the operation has been completed.
From a performance perspective this design is great as it avoids delaying operation while the post processing is done. But it limits the functionality that can be achieved in such an after event. E.g. as the after event fires asynchronously on a different thread it is not guaranteed that the code implemented in an after event has been completed when additional operations are performed later. As the processing of the after event also fires on a different thread it is also not possible to redirect to a different page from within the after event as neither the HttpContext object from the request initiating the original operation is available nor is it guaranteed that the after event is executed before the response of the original request has been sent back to the browser.
To overcome this limitation SharePoint 2010 has additional functionality to allow synchronous execution of after events. The default is still asynchronous but you can now configure your after event explicitly to execute synchronous.
The easiest way to achieve this is to modify the elements.xml file of the feature which registeres the event receiver as outlined in the following article: http://msdn.microsoft.com/de-de/library/gg981880.aspx
In case that the event receiver is registered programmatically you can achieve the same result by setting the Synchronization property of the SPEventReceiverDefinition object to SPEventReceiverSynchronization.Synchronous