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

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

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

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

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

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

waitEvent.WaitOne( 0 )

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

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

Я пропустил что-нибудь важное здесь?

Спасибо!


.net c# thread-safety waithandle
person Robert Altman    schedule 09.01.2012    source источник

Ответы (2)


arrow_upward
0
arrow_downward

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

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

person FMM    schedule 09.01.2012
comment
Мои мысли точно. При прочих равных, я склонен думать, что разница в производительности во время выполнения не стоит риска испортить дизайн, когда я буду обновлять его через 6-12 месяцев. - person Robert Altman; 09.01.2012
comment
Я думаю, вы сами ответили на свой вопрос. Не то чтобы я был против получить дополнительную репутацию за свой ответ или что-то в этом роде :) - person FMM; 10.01.2012
comment
Да, но я подумал, что стоит проверить работоспособность на случай, если я что-то упустил. Как независимый разработчик, я часто упускаю возможность обсудить архитектуру с другими опытными разработчиками; так что вы заработали дополнительную репутацию. - person Robert Altman; 10.01.2012
comment
Такова судьба яркого разработчика, работающего самостоятельно. Приятно, что у нас есть неограниченный запас цифровой валюты для обмена в обмен на помощь в программировании. Спасибо, и удачи вам! - person FMM; 11.01.2012

arrow_upward
0
arrow_downward

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

person Brad Semrad    schedule 09.01.2012