none
ManualResetEvent or AutoResetEvent RRS feed

  • Question

  • Hello,

    When should I use ManualResetEvent and when should I use AutoResetEvent?

    I mean ManualResetEvent is more correct. Can someone explain it well and in short?

    If I call AutoResetEvent and check if the event is set with WaitOne, I have the impression that it is not set again.

    With ManualResetEvent I get my use case better done. I just want to understand it.

    Thanks for tips in advance.

    Greetings Markus

    Thursday, January 23, 2020 5:50 PM

Answers

  • There is a good discussion of the difference at https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-createeventw

    "When the state of a manual-reset event object is signaled, it remains signaled until it is explicitly reset to nonsignaled by the ResetEvent function. Any number of waiting threads, or threads that subsequently begin wait operations for the specified event object, can be released while the object's state is signaled.

    When the state of an auto-reset event object is signaled, it remains signaled until a single waiting thread is released; the system then automatically resets the state to nonsignaled. If no threads are waiting, the event object's state remains signaled."

    Thursday, January 23, 2020 6:01 PM
  • > ManualResetEvent is more correct.

    No, it is absolutely not more correct.  You have made the fatal mistake of assuming that every problem is like your problem.  Each type has its uses, and you need to use the right one for your need.  I have generally found the auto reset to be more useful.

    Consider, for example, a server that has one thread receiving requests and multiple threads that can handle those requests.  The handler threads will all be sitting on a WaitOne.  When the server has a new request, it puts it onto a queue and signals the event.  In this case, you CLEARLY need an auto reset event.  One of the threads will be awakened to handle the request, and the event will automatically be reset so that the other threads do not wake up.  One event, one wake up, and automatically reset.


    Tim Roberts | Driver MVP Emeritus | Providenza & Boekelheide, Inc.

    Friday, January 24, 2020 8:05 AM

All replies

  • There is a good discussion of the difference at https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-createeventw

    "When the state of a manual-reset event object is signaled, it remains signaled until it is explicitly reset to nonsignaled by the ResetEvent function. Any number of waiting threads, or threads that subsequently begin wait operations for the specified event object, can be released while the object's state is signaled.

    When the state of an auto-reset event object is signaled, it remains signaled until a single waiting thread is released; the system then automatically resets the state to nonsignaled. If no threads are waiting, the event object's state remains signaled."

    Thursday, January 23, 2020 6:01 PM
  • > ManualResetEvent is more correct.

    No, it is absolutely not more correct.  You have made the fatal mistake of assuming that every problem is like your problem.  Each type has its uses, and you need to use the right one for your need.  I have generally found the auto reset to be more useful.

    Consider, for example, a server that has one thread receiving requests and multiple threads that can handle those requests.  The handler threads will all be sitting on a WaitOne.  When the server has a new request, it puts it onto a queue and signals the event.  In this case, you CLEARLY need an auto reset event.  One of the threads will be awakened to handle the request, and the event will automatically be reset so that the other threads do not wake up.  One event, one wake up, and automatically reset.


    Tim Roberts | Driver MVP Emeritus | Providenza & Boekelheide, Inc.

    Friday, January 24, 2020 8:05 AM