Why don't AutoResetEvent and ManualResetEvent support name in constructor?
In the .NET Framework 2.0, AutoResetEvent and ManualResetEvent inherit from EventWaitHandle. The EventWaitHandle class has 4 different constructors. 3 support for constructors for naming an event. On the other hand, both ManualResetEvent and AutoResetEvent do not support naming and provide a single constructor that receives initialState. I can just inherit from EventWaitHandle and write my own implementation of those classes that support all constructor overloads, but I don't like reinventing the wheel if I don't need to. My questions:
- Is there a particular problem when naming events?
- Do you have any ideas why Microsoft doesn't support it?
- Do you have a better suggestion than inheriting from the EventWaitHandle class and calling the appropriate constructor like 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)
{
}
}
a source to share
You can create a named reset manual like:
// Open the event by name.
EventWaitHandle namedMRSE =
new EventWaitHandle(false, EventResetMode.ManualReset, @"TheName");
Here is the link for the above code. I don't know the specific reason for the design, but there are a few notes on msdn that suggest there is a difference based on the application domain and process:
Event handles are useful in many of the same timing scenarios as the Monitor class. The pending handle event is often easier to use than the System.Threading.Monitor.Wait and System.Threading.Monitor.Pulse (System.Object) methods, and they offer more control over the signaling. Named event pending handles can also be used to synchronize activities across application domains and processes, whereas monitors are local to the application domain.
a source to share