« first day (891 days earlier)      last day (2140 days later) » 

vitidev
vitidev
3:45 AM
@VladD Есть "concurrent list" в который что то добавляется и удаляется многопоточно и есть события добавлено/удалено и так далее.
Стоит задача в некоторый момент создать ViewModel в котором отобразить состояние и далее отображать изменения. То есть нужно подписаться, вычитать и отобразить контент и потом еще следить за подпиской

Ну...варианты
1) lock(this/lockState) на время вычитывания - работать будет, но стоит где то забыть их вызвать и будут проблемы. В общем бяка
2) сначала подписаться на события и пока мы получаем и рисуем состояние все изменения буферизировать и по окончанию отрисо…
 
 
6 hours later…
VladD
VladD
9:59 AM
@vitidev А события многопоточные?
Потому что многопоточные события -- это скорее всего race condition на клиенте
1) Ну да, традиционный подход.
2) А буфера нужно точно так же лочить?
3) Если события доставляются в произвольном потоке, то это не будет работать, правильно?
 
 
10 hours later…
vitidev
vitidev
7:50 PM
@VladD 1) внутри обычный массив и использует внутренний lock на своей коллекции. Так что вызов событий не гонится. Но это не спасет от "между подписался и забираю основной список накидали еще элементов".
2)Буферы лочить нельзя - будет дедлок. А раз нет гонки, то и не нужно, но это уже нужно знать детали реализации того "списка", чтобы знать что можно, а что нет.
3) да. будет плохо, но пункт 1 и состояния гонки нет.

нужно соединить события "подписался, вычитываю данные и ничего не потерял". lock(lockState) можно забыть, буферы требуют знания реализации чтобы не было дидлоков и только решени…
 
VladD
VladD
8:15 PM
@vitidev Чёта мне это не нравится.
А почему бы не сделать вот как:
Если пришла нотификация об изменении, включать таймер, и через N миллисекунд под блокировкой считать всю коллекцию. (Таймер нужен, чтобы не было слишком частых обновлений.) После считывания коллекции медленно и вдумчиво обновить UI. Повторять до бесконечности.
Или, возможно, сама идея с коллекцией, в которую пишут кто хочет, и она отправляет события откуда хочет, порочна. Другая идея: пусть коллекция будет однопоточной и живёт в STA. Я бы сделал так.
 
 
2 hours later…
vitidev
vitidev
10:13 PM
@VladD так коллекция может жить как хочет. Важно где живет читатель. А он живет в UI потоке, а коллекцию (сервис) в UI потоке держать ну никак нельзя. В итоге получаем ту же самую проблему - мы забрали элементы и пока мы их рисуем пришли новые элементы. А вот перечитваение всей коллекции для поиска "чо там нового " мне уже не нравится. это и хешсет нужен для скорости и опять же планировать все в одном потоке
 
VladD
VladD
10:58 PM
@vitidev А хорошо ли, чтобы коллекция жила как хочет? У вас в этом случае гарантированы out-of-order-события в наблюдающем потоке. Впрочем, хозяин — барин.
@vitidev Планировку (то есть, выявление обновлений из снэпшота) можно бы вынести и в отдельный поток. Но я бы всё же заставил коллекцию быть STA и не мучился бы. Было бы на порядок легче. Многопоточные события = открыть самому себе врата ада.
 

« first day (891 days earlier)      last day (2140 days later) »