Я работаю над программой, которая реагирует на события, поступающие из интернет-сокета, и, возможно, также от таймеров.Кажется естественным использовать два потока:
- Один для основной программы
- Второй, который прослушивает сокет, анализирует ввод и вызывает соответствующее событие.
Дополнительные требования:
- Приложение не должно полагаться на поток пользовательского интерфейса (его можно запустить как консольное приложение).
- Основная программа должна обрабатывать сообщения синхронно, то есть в том порядке, в котором они поступили.
- Главный поток не должен блокироваться при ожидании таймеров (я полагаю, это означает, что я должен запускать таймеры наразные темы).
А теперь несколько вопросов: -):
- Я предполагаю, что требование № 1 означает, что у меня нет встроенного сообщениянасос, поэтому я не могу использовать
Invoke()
из потоков слушателя / таймера сокета.Это правильно? - Как можно безопасно вызывать события в одном потоке (например, в прослушивателе) и синхронно запускать подписчики в другом потоке (основном потоке)?
- Весьма вероятно, чтоновые события будут вызваны до того, как будет сделан следующий обработчик.Что будет в этом случае?Будет ли событие буферизовано где-то CLR или оно будет проигнорировано?
И последнее, но не менее важное: я предполагаю, что стремлюсь к параллели для парадигмы «производитель / потребитель», но вместо этогосообщений, я хочу использовать события.Как вы думаете, есть лучший подход?
Спасибо,
Боаз
РЕДАКТИРОВАТЬ
Я хочу объяснить мою мотивацию дляиспользуя события в первую очередь.Приложение представляет собой автоматизированный торговый механизм, который должен реагировать на события, происходящие на рынке (например, изменение цены акции).Когда это происходит, в главном потоке может быть несколько подписчиков, которые следует вызывать, что является классическим сценарием использования событий.
Полагаю, я всегда могу использовать Producer / Consumer с какой-либо очередью сообщений и получать от потребителей события в главном потоке, но я подумал, что может быть более прямой путь.