The Moth

As part of some restructuring for my app, I had to dig into the abstract System.Threading.WaitHandle class. As you'd expect, this is different on NETCF to the Full Fx, and both have changed with Whidbey (based on November CTP).

NETCF 1.0 vs .NET 1.1
The CF version does not provide the WaitAll or WaitAny methods; it only provides the basic parameterless overload of WaitOne. Comparing the total number of members (fields, properties, methods) regardless of scope, we find the CF version having half the members than the Full Fx (13 vs 26).

.NET 1.1 vs .NET 2.0
The main addition we'll get is the public static SignalAndWait methods (3 overloads). The class grows by 9 members in total. The other change is the replacement of the Handle type. Instead of using an IntPtr, it is now of the newly introduced SafeWaitHandle (of the new Microsoft.Win32.SafeHandles namespace)

NETCF 1.0 vs NETCF 2.0The WaitHandle in CF 2.0 brings no changes compared to CF 1.0 apart from implementing the IDisposable.Dispose method (that the Full Fx classes do in all versions).

Getting to the point
So why am I looking at this class? Well actually, I am not interested in the class itself; it is the derived classes that are interesting, and to understand an object's behaviour you must understand its parents. In .NET 1.1 and NETCF 1.0 the public inheritance relationship is:

Figure A
 WaitHandle : MarshalByRefObject
  |-> Mutex
  |-> AutoResetEvent
  |-> ManualResetEvent

In .NET 2.0 this changes with the introduction of a new class (and the one that interests me) EventWaitHandle:

Figure B
 WaitHandle : MarshalByRefObject
  |-> Mutex
  |-> EventWaitHandle
   |-> AutoResetEvent
   |-> ManualResetEvent
  |->Semaphore

EventWaitHandle is not supported in CF 2.0 and, in fact, the whole inheritance hierarchy remains the same in CF 2.0 as it is today (i.e. Figure A). Ignoring Semaphore for the time being (maybe a subject of a future post), I would have urged you to go vote but the inclusion of EventWaitHandle to NETCF has already been postponed.

The main use of this class would be for creating named events which play a prominent role in Inter-Process Communication on WinCE.

Next time we'll look at wrapping the pinvokes required to offer a class that exposes the same interface as EventWaitHandle (unfortunately, though, it cannot fit in the same inheritance hierarchy as the desktop, i.e. we cannot change the existing Compact Framework XXXXResetEvent classes to inherit from the EventWaitHandle we introduce, rather than the WaitHandle that they do).