如何在C＃中检查AutoResetEvent或ManualResetEvent的阻塞状态？

Question

是否可以在调用WaitOne（）之前检查C＃System.Threading.AutoResetEvent或System.Threading.ManualResetEvent的阻塞状态？

Answer 1

An EventWaitHandle doesn't have a "blocking state". It is set or reset, nothing else. And no, you cannot check that any other way than by calling WaitOne().

You can pass a 0 for the time-out argument to avoid blocking. That's often a very bad idea because it says nothing about the state of the event after the WaitOne() call returns. It might have changed a nanosecond after that. This causes a very nasty kind of bug called "threading race". A Heisenbug.

Answer 2

Use

public virtual bool WaitOne(
    TimeSpan timeout
)

with timeout 0. According to MSDN it will return the state of the WaitHandle immediately.

Answer 3

I had the same question, really just building a demo app. (Newbie to EventWaitHandle.)

This is how I solved the problem (in VB.NET):

Module Module1

Dim ewh As Threading.EventWaitHandle

Sub Main()
  ewh = New Threading.EventWaitHandle(False, Threading.EventResetMode.ManualReset)
  ' Do other work.
End Sub

Sub checkBlockStatus()

  ewh.WaitOne()

End Sub

Function isEwhBlocked() As Boolean

  Dim testEwhBlock As New Threading.Thread(AddressOf checkBlockStatus)
  testEwhBlock.Start()
  Threading.Thread.Sleep(1000)
  If testEwhBlock.ThreadState <> Threading.ThreadState.Stopped Then
     ' It's OK to use abort here because I don't care what happens to the thread.
     testEwhBlock.Abort()
     Return True
  Else
     Return False
  End If
  testEwhBlock = Nothing

End Function
End Module

At any point that you need to check the blocking status of that instance, just do this:

if (isEwhBlocked()) Then
  ' This means the block is on.
else
  ' No block.
End If

So, no, you can't REALLY figure out what is blocked before calling WaitOne(), but you can run it in an ASync way that prevents it from seizing your main thread. You could probably reduce the sleep value quite a bit as well, if that is too long to wait.

Obviously, if you need to check on multiple blocks, the function gets a tad bit more complex (or you have to create more of them), but this demonstrates the basic principle. I also tested this as an AutoReset, and it doesn't work quite as well. Because the handler is in autoreset, once I call the method to check the block, it resets and blocks my other thread. So if you can run in ManualReset, this could work for you.