none
When and why would one use the AutoResetEvent over ManualResetEvent? RRS feed

  • Question

  • Hi all,

    I am trying to understand the need and essence of the AutoResetEvent. Can anyone give me an example where only a AutoResetEvent can be used and ManualResetEvent cannot be used?

    Also I have read that when the ManualResetEvent is Set(signaled state) then all the waiting threads get the go ahead. All the waiting threads means the threads which were made to wait by calling the WaitOne() method on the manualResetEvent object which is Set or all the waiting threads in general.
    Tuesday, January 26, 2010 2:09 PM

Answers

  • As far as I know, an AutoResetEvent is a no-brainer version of ManualResetEvent: when you don't need the extra control provided by a ManualResetEvent, you stick to AutoResetEvent because it spares you work.

    Coming to think of it (but don't worry, on 70-536 exam there are no questions this deep on WaitHandles :) ), I may add that an AutoResetEvent does not suffer of the delay of a ManualResetEvent when resetting, so if you have multiple threads entering and exiting Wait state at fast pace, it's probably safer to use an AutoResetEvent, to be sure that the Wait() is consistent as soon as possible (when ticks do matter, at least). A practical example? I'm thinking when you are monitoring pins of serial communication on a serial port, and you need to raise and lower your DTR fast basing on multiple thread data, probably I would use an AutoResetEvent instance, to be sure to not lose any useful thread that should wait while I'm resetting the WaitHandle. I'm sorry I can't think a more everyday scenario, though.

    About the Set() of the WaitHandles, they influence all threads waiting on that specific WaitHandle and all threads on a WaitAll()/WaitAny() (according to the Wait call specifications, of course).


    -- Alessio Massuoli
    • Proposed as answer by SamAgain Thursday, February 4, 2010 9:47 AM
    • Marked as answer by SamAgain Friday, February 5, 2010 9:33 AM
    Tuesday, January 26, 2010 3:21 PM
  • Hi, Amateur developer:
        I believe that you have read all the MSDN entries for AutoResetEvent & ManualResetEvent. There're very good code samples there. 
       
        First, you should make it clear the following relationship between types:

        WaitHandle <- EventWaitHandle <- AutoResetEvent & ManualResetEvent

       These types are used for thread syncronization.

       [WaitHandle]: Encapsulates operating system–specific objects that wait for exclusive access to shared resources.This class is typically used as a base class for synchronization objects. Classes derived from WaitHandle define a signaling mechanism to indicate taking or releasing access to a shared resource, but use the inherited WaitHandle methods to block while waiting for access to shared resources.

       [EventWaitHandle]: Represents a thread synchronization event. The EventWaitHandle class allows threads to communicate with each other by signaling.

       [AutoResetEvent]: Notifies a waiting thread that an event has occurred.

       [ManualResetEvent]: Notifies one or more waiting threads that an event has occurred. 

       Let's make an analogy:
       The AutoResetEvent is kind of like a revolving door. It allows one thread pass each time it's open(set).
       The ManualResetEvent is just a regular door. Once it's opened(set), any number of threads waiting on it could pass through it until it's closed again(reset).
       
       The typical scenario for ManualResetEvent is:
       When a thread begins an activity that must complete before other threads proceed, it calls Reset to put ManualResetEvent in the non-signaled state. This thread can be thought of as controlling the ManualResetEvent. Threads that call WaitOne on the ManualResetEvent will block, awaiting the signal. When the controlling thread completes the activity, it calls Set to signal that the waiting threads can proceed. All waiting threads are released.

       Hope these explanations could be helpful.  



    Please mark the right answer at right time.
    Thanks,
    Sam
    • Edited by SamAgain Thursday, February 4, 2010 9:45 AM refine
    • Proposed as answer by SamAgain Thursday, February 4, 2010 9:47 AM
    • Marked as answer by SamAgain Friday, February 5, 2010 9:33 AM
    Thursday, February 4, 2010 9:40 AM

All replies

  • As far as I know, an AutoResetEvent is a no-brainer version of ManualResetEvent: when you don't need the extra control provided by a ManualResetEvent, you stick to AutoResetEvent because it spares you work.

    Coming to think of it (but don't worry, on 70-536 exam there are no questions this deep on WaitHandles :) ), I may add that an AutoResetEvent does not suffer of the delay of a ManualResetEvent when resetting, so if you have multiple threads entering and exiting Wait state at fast pace, it's probably safer to use an AutoResetEvent, to be sure that the Wait() is consistent as soon as possible (when ticks do matter, at least). A practical example? I'm thinking when you are monitoring pins of serial communication on a serial port, and you need to raise and lower your DTR fast basing on multiple thread data, probably I would use an AutoResetEvent instance, to be sure to not lose any useful thread that should wait while I'm resetting the WaitHandle. I'm sorry I can't think a more everyday scenario, though.

    About the Set() of the WaitHandles, they influence all threads waiting on that specific WaitHandle and all threads on a WaitAll()/WaitAny() (according to the Wait call specifications, of course).


    -- Alessio Massuoli
    • Proposed as answer by SamAgain Thursday, February 4, 2010 9:47 AM
    • Marked as answer by SamAgain Friday, February 5, 2010 9:33 AM
    Tuesday, January 26, 2010 3:21 PM
  • Hi, Amateur developer:
        I believe that you have read all the MSDN entries for AutoResetEvent & ManualResetEvent. There're very good code samples there. 
       
        First, you should make it clear the following relationship between types:

        WaitHandle <- EventWaitHandle <- AutoResetEvent & ManualResetEvent

       These types are used for thread syncronization.

       [WaitHandle]: Encapsulates operating system–specific objects that wait for exclusive access to shared resources.This class is typically used as a base class for synchronization objects. Classes derived from WaitHandle define a signaling mechanism to indicate taking or releasing access to a shared resource, but use the inherited WaitHandle methods to block while waiting for access to shared resources.

       [EventWaitHandle]: Represents a thread synchronization event. The EventWaitHandle class allows threads to communicate with each other by signaling.

       [AutoResetEvent]: Notifies a waiting thread that an event has occurred.

       [ManualResetEvent]: Notifies one or more waiting threads that an event has occurred. 

       Let's make an analogy:
       The AutoResetEvent is kind of like a revolving door. It allows one thread pass each time it's open(set).
       The ManualResetEvent is just a regular door. Once it's opened(set), any number of threads waiting on it could pass through it until it's closed again(reset).
       
       The typical scenario for ManualResetEvent is:
       When a thread begins an activity that must complete before other threads proceed, it calls Reset to put ManualResetEvent in the non-signaled state. This thread can be thought of as controlling the ManualResetEvent. Threads that call WaitOne on the ManualResetEvent will block, awaiting the signal. When the controlling thread completes the activity, it calls Set to signal that the waiting threads can proceed. All waiting threads are released.

       Hope these explanations could be helpful.  



    Please mark the right answer at right time.
    Thanks,
    Sam
    • Edited by SamAgain Thursday, February 4, 2010 9:45 AM refine
    • Proposed as answer by SamAgain Thursday, February 4, 2010 9:47 AM
    • Marked as answer by SamAgain Friday, February 5, 2010 9:33 AM
    Thursday, February 4, 2010 9:40 AM