Why AutoResetEvent and ManualResetEvent does not support name in the constructor?

Question

On .NET Framework 2.0 AutoResetEvent and ManualResetEvent inherit from EventWaitHandle. The EventWaitHandle class has 4 different constructors. 3 of the constructors support giving a name to the event. On the other hand both ManualResetEvent and AutoResetEvent do not support naming and provide a single constructor that receives the initialState. I can simply inherit from EventWaitHandle and write my own implementation of those classes that support all the constructor overloads, but I don't like to re-invent the wheel if I do not have to. My questions are:

• Is there a special problem in naming events?
• Do you have any idea why Microsoft did not support it?
• Do you have a proposal better than inheriting from the EventWaitHandle class and calling the appropriate constructor as in the following example?

    public class MyAutoResetEvent: EventWaitHandle  
    {  
        public MyAutoResetEvent(bool initialState)  
            : base(initialState, EventResetMode.AutoReset)  
        {  
        }  
        public MyAutoResetEvent(bool initialState, string name)  
            : base(initialState, EventResetMode.AutoReset, name)  
        {  
        }  
        public MyAutoResetEvent(bool initialState, string name, out bool createdNew)  
            : base(initialState, EventResetMode.AutoReset, name, out createdNew)  
        {  
        }  
        public MyAutoResetEvent(bool initialState, string name, out bool createdNew, EventWaitHandleSecurity eventSecurity)  
            : base(initialState, EventResetMode.AutoReset, string.Empty, out createdNew, eventSecurity)  
        {  
        }  
    }  

Answer 1

You can make a named manual reset event like so:

// Open the event by name.
EventWaitHandle namedMRSE = 
    new EventWaitHandle(false, EventResetMode.ManualReset, @"TheName");

Here is the reference for the above code. I don't know of the particular reason behind the design, but there are some notes on msdn that suggest there is a distinction based on the application domain and the process:

Event wait handles are useful in many of the same synchronization scenarios as the Monitor class. Event wait handles are often easier to use than the System.Threading.Monitor.Wait and System.Threading.Monitor.Pulse(System.Object) methods, and they offer more control over signaling. Named event wait handles can also be used to synchronize activities across application domains and processes, whereas monitors are local to an application domain.