none
Продолжительность пребывания ManualResetEventSlim в установленном состоянии RRS feed

  • Вопрос

  • В приложении определен экземпляр ManualResetEventSlim с аргументом true в конструкторе (т.е. изначально в установленном состоянии). В этом же приложении работают три потока "А", "В" и "С". В потоке "А" вызывается функция Wait(). Т.к. ManualResetEventSlim изначально в установленном состоянии, то "А" не ждёт на вызове Wait(), а благополучно проходит его и выполняется дальше. В потоке "В" при достижении определённой ситуации вызывается Reset(), что бы остановить поток "А". Поток "С" проверяет состояние потока "А" и если оно WaitSleepJoin, то выполняет некоторые вычисления и затем вызывает Set() для перевода ManualResetEventSlim в сигнальное состояние, что бы разрешить дальнейшее выполнение "А". У меня вопрос следующий. Если экземпляр ManualResetEventSlim (или там экземпляр AutoResetEvent) долгое время находится в сигнальном состоянии, скажем от 3-х до 6-ти часов, то он этим не повлияет отрицательно на работу приложения?
    27 августа 2012 г. 6:42

Ответы

  • Добрый день.

    Если вы заранее знаете, что периоды ожидания будут длительными, то смысла использовать Slim версию нет. Вот что про него написано в рекомендациях по использованию:

    ---

    .ManualResetEventSlim class for better performance when wait times are expected to be very short, and when the event does not cross a process boundary. ManualResetEventSlim uses busy spinning for a short time while it waits for the event to become signaled." id="mt7" xml:space="preserve">В .NET Framework 4 можно использовать класс System.Threading.ManualResetEventSlim для повышения производительности, когда периоды ожидания должны быть короткими, а событие не выходит за рамки процесса. ManualResetEventSlim использует цикличную работу в режиме занятости в течение короткого промежутка времени, пока ожидает сигнала от события.  Если периоды ожидания короткие, цикличная работа может быть намного дешевле ожидания с использованием дескрипторов ожидания.  ManualResetEventSlim обращается к стандартному дескриптору ожидания события.

    ---

    Т.е. при длительном ожидании он работает аналогично ManualResetEvent, а Slim версия оправдана только при коротких ожиданиях.

    • Предложено в качестве ответа Abolmasov Dmitry 28 августа 2012 г. 6:22
    • Помечено в качестве ответа TownSparrow 29 августа 2012 г. 6:50
    27 августа 2012 г. 13:44
    Отвечающий
  • Используйте ManualReselEvent, как сказал Алексей. Отрицательно на производительность это повлиять не должно.

    Для связи [mail]

    • Помечено в качестве ответа TownSparrow 29 августа 2012 г. 6:50
    28 августа 2012 г. 6:21

Все ответы

  • Добрый день.

    Если вы заранее знаете, что периоды ожидания будут длительными, то смысла использовать Slim версию нет. Вот что про него написано в рекомендациях по использованию:

    ---

    .ManualResetEventSlim class for better performance when wait times are expected to be very short, and when the event does not cross a process boundary. ManualResetEventSlim uses busy spinning for a short time while it waits for the event to become signaled." id="mt7" xml:space="preserve">В .NET Framework 4 можно использовать класс System.Threading.ManualResetEventSlim для повышения производительности, когда периоды ожидания должны быть короткими, а событие не выходит за рамки процесса. ManualResetEventSlim использует цикличную работу в режиме занятости в течение короткого промежутка времени, пока ожидает сигнала от события.  Если периоды ожидания короткие, цикличная работа может быть намного дешевле ожидания с использованием дескрипторов ожидания.  ManualResetEventSlim обращается к стандартному дескриптору ожидания события.

    ---

    Т.е. при длительном ожидании он работает аналогично ManualResetEvent, а Slim версия оправдана только при коротких ожиданиях.

    • Предложено в качестве ответа Abolmasov Dmitry 28 августа 2012 г. 6:22
    • Помечено в качестве ответа TownSparrow 29 августа 2012 г. 6:50
    27 августа 2012 г. 13:44
    Отвечающий
  • Используйте ManualReselEvent, как сказал Алексей. Отрицательно на производительность это повлиять не должно.

    Для связи [mail]

    • Помечено в качестве ответа TownSparrow 29 августа 2012 г. 6:50
    28 августа 2012 г. 6:21