Может ли ManualResetEvent использоваться для замены логического

Question

Это, по общему признанию, необычный вопрос; Я бы никогда не рекомендовал заменять логическое значение на ManualResetEvent в типичной разработке .NET. В этом случае мне уже нужен ManualResetEvent, чтобы указать состояние соединения с другим потоком; Учитывая это, мне приходит в голову, что использование логического значения с тем же семантическим значением является излишним.

ОК, особенности: у меня есть рабочий поток, который должен обрабатывать сообщения, когда выполняются следующие условия:

• «Клиент» подключен
• «Получатель» подключен

Соединения "клиент" и "получатель" - это сокеты TCP, которые отслеживаются другими потоками; при изменении состояния подключения соответствующий WaitHandle будет установлен (подключен) или сброшен (отключен).

Первоначально у меня было логическое значение состояния соединения (для пользовательского интерфейса). Теперь, когда я использую WaitHandles для сигнализации рабочего потока, представляется целесообразным полностью исключить логические переменные состояния и просто использовать WaitHandles.

waitEvent.WaitOne( 0 )

возвращает состояние дескриптора без блокировки, что делает его функционально идентичным проверке логического значения (с дополнительным преимуществом поточно-ориентированной работы).

Итак, учитывая, что я уже собираюсь использовать WaitHandles, и мне не нравится идея сохранения состояния (одного и того же семантического значения) в двух разных переменных, есть ли причина, по которой я не могу просто использовать WaitHandles? Наиболее значимым контраргументом, который я могу придумать, является производительность во время выполнения: время для проверки логического значения и время для проверки WaitHandle; но я не думаю, что это сильно повлияет на производительность.

Я что-то здесь упускаю?

Спасибо!

Answer 1

Преимущество простого использования ManualResetEvent состоит в том, что у вас есть только одна переменная, отслеживающая одно и то же состояние. Однако, как вы упомянули, для чтения состояния потребуется дополнительная информация.

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

Answer 2

Есть несколько способов ведения дел.Это один из таких случаев.Не должно быть никакой разницы, если вы правильно используете логическое значение.Одним из соображений будет память (объект занимает больше логического значения), но, скорее всего, незначительный.Либо я бы порекомендовал, но так как вы используете Threading для сигнализации о событиях, я бы предложил WaitHandles, поскольку они предназначены именно для этого.