Threadsafe observer pattern

Question

Я пишу приложение для WPF в шаблоне MVC. Цель приложения - отобразить некоторые данные в базе данных, и эти данные обновляются асинхронно.

Я подумываю о том, как проектировать архитектуру, чтобы она была потокобезопасной. В частности:

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

Очевидно, что страница, которая только что закрывается, должна отказаться от подписки на услугу, а страница, которая только что появляется, должна (или может) подписаться.

я мог бы поставить подписку внутри критической секции, а также передачи о новых данных, но представьте себе следующий сценарий (стр ~ = его ViewModel, это не имеет большого значения, здесь):

• служба входит критический раздел для передачи информации о новых данных (в отдельном потоке)
• Страница пытается войти в критический раздел, чтобы отказаться от подписки (в основном потоке)
• Служба сообщает страницу о новых данных (в отдельной теме).
• Страница заполняет поля и вызывает событие PropertyChange (в отдельном потоке).
• Событие PropertyChange сортируется по основному потоку. Который ждет критический раздел.

И это похоже на тупик для меня.

Как я могу безопасно спроектировать эту архитектуру, чтобы избежать таких взаимоблокировок? Возможно, страницы никогда не должны отписываться? Или есть другой способ защитить потоки, чтобы они не зашли в тупик?

Answer 1

Учитывая, что сообщение помечено WPF и WP-8.1 и разъяснение в комментариях, я хотел бы сделать следующее:

1. Есть базовый класс модели (один со свойствами, имеющих соответствующие данные) осуществлять INotifyPropertyChanged
2. Имейте модель для ВСЕХ страниц как ObservableCollection<BaseModel>. Модель также должна реализовать свойство mutex/lock, созданное в конструкторе.
3. Поделитесь моделью на всех моделях (например, поделитесь экземпляром модели).
4. В выполнении операции async «Сервис» я бы только lock раздел кода, который бы Add или Remove элементов из модели ObservableCollection с использованием объекта блокировки самой модели. Этот раздел ДОЛЖЕН быть размещен в вызове Dispatcher.Invoke() или эквивалентной платформе. Это гарантирует, что только поток пользовательского интерфейса ожидает обновления коллекции.
5. Я бы привязал весь пользовательский интерфейс на соответствующих страницах к ссылке на модель в модели viewmodel.

Таким образом, пользовательский интерфейс и ViewModels небрежны к конкретным событиям обслуживания, таким образом, устраняя накладные расходы подписываться, и вы также ограничить дублирование данных, если вы разделяете модель - даже с 20 страниц на экране, ваша служба будет выполнять одно обновление, которое распространяется на пользовательский интерфейс и режимы представления по полномочиям структуры (привязки).

Answer 2

Простым решением может быть: Не выполнять операцию отмены подписки в потоке пользовательского интерфейса. (В общем, не блокируйте поток пользовательского интерфейса.) Сделайте это асинхронно, стреляйте и забывайте.

В качестве альтернативы вы можете взглянуть на Rx (Reactive Extensions), что именно для этой цели: Реализация шаблона наблюдателя многопоточным способом.

---

Безмолвно «просто не отписаться», вероятно, не очень хорошая идея. Хотя я не знаю ваших деталей реализации, если обработчики событий являются методами экземпляра, то ссылка на этот экземпляр неявно будет храниться службой, и в зависимости от ссылочной цепочки, возможно, ваша страница или другие экземпляры будут предотвращены для сбора мусора.

---

«Или есть другой способ защитить потоки, чтобы они не зашли в тупик?» В настоящее время в среде .NET нет волшебного трюка, который автоматически предотвращает тупик. Другие многопоточные среды могут или не могут обеспечивать автоматический тупик разрешение (обратите внимание: не профилактическое) обслуживание, что может обнаружить тупик (после его возникновения) и автоматически выбрать жертву. В .NET это может быть исключение, что происходит пока вы ожидаете своего ресурса. (опять же это еще не реализовано)