Здравствуйте. Кто имел дело с synchronizedList, посоветуйте пожалуйста. Проблема в следующем. Существует несколько потоков одни потоки добавляют в лист элементы, другие удаляют, а третьи просто перебирают их. Как их синхронизировать? Т.е как сделать так, чтобы когда один поток занимается своим делом, то другие ждут пока он его освободит. И можно ли для таких листов использовать foreach? Заранее огромное спасибо за помощь!

BlazkowiczКроме прочего можно и read\write операции к списку обезопасить без "синхронизации". Использовать ReadWriteLock и LinkedList, например.

Можно пример? Спасибо.

Так... Если использовать CopyOnWriteArrayList, то можно не парится и он сам позаботится о синхронизации?

Blazkowicz,

Очень часто перебор и удаление. И не должно быть ситуации когда один поток удалил элемент, а другой в этот момент перебирал и наткнулся на него.

schwa,

Что посоветуете?

Blazkowicz,

Ок... Сетевое приложение. TCP сервер. При подключении клиента создается экземпляр объекта(сессии) ссылка на который добавляется в synchronizedList, так же в этот объект(сессию) передается ссылка на этот самый лист. При отключении сессия должна вызвать synchronized функцию в которой произведет запись в БД, а потом удалить себя из списка. При этом еще живые сессии могут перебирать коллекцию этих самых сессий и взаимодействовать с ними. Как быть?

schwa,

Очень критичны расходы на память. Как я понял при чтении списка будет создаваться копия объекта листа и производится перебор. Так?

BlazkowiczА что если поток который перебирал, обработает элемент на миллисекунду раньше чем другой поток его удалит? А если позже? А на что эта миллисекунда влияет в вашей системе?
Так.. Так вот я и спрашиваю. Как сделать так чтобы к примеру один из потоков читает список, то все остальные ждут. Независимо от того что они собираются делать. И наоборот.

И еще... В момент отключения и удаления элемента, если элемент связан с другим элементом, то он сообщает ему об этом. К примеру если потоки взаимодействуют друг с другом(существует друг на друга ссылка) и в один прекрасный момент один из них решил отключится и удалится из списка, то он сообщает об этом своему потоку-партнеру. Так что ничего страшного. Это работает уже довольно стабильно год. Но иногда возникают проблемы. Как я понял они связанны с синхронизацией. Хочется поправить этот момент.

Blazkowicz,

Попробую объяснить поподробнее. Приложение это это сервер который позволяет обходить NAT. Т.е соединять два TCP клиента. Представьте есть приложение сервер которое ставиться на ПК и приложение клиент которое ставится на смартфон. Приложение которое на ПК должно как-то себя определить и идентифицироваться клиентом. Так вот. Это приложение производит регистрацию на сервере путем создания пары логин-пароль который естественно сохраняется в БД. После оно авторизируется на этом сервере и на сервере создается объект(сессия-сокет) в котором есть поле которое определяет его тип Server(ПК) или Client(смартфон) и естественно добавляется в synchronizedList. Возникает момент когда клиент(самртфон) хочет подключиться к Server(ПК) он подключается к серверу(тот самый к которому подключаются все) на нем создается опять же объект(сессия-сокет) в поле которого определяется что он клиент. Далее он производит поиск по synchronizedList и ищет есть ли в списке тот самый подключенный ПК, если есть, то они обмениваются ссылками друг на друга и производят взаимодействие(обмен данными). Но вдруг возникает ситуация и один из них отключается... Тут-то и происходит удаление... А в этот момент кто-то ищет себе пару для взаимодействия. Надеюсь понятно объяснил. По такому типу работает такая замечательная программа как TeamViewer и подобные включая мое приложение.

Сейчас используется конструкция типа




Но как я понимаю этот путь неверный...

Blazkowicz,

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

BlazkowiczИ, снова, непонятно откуда требования в немедленном удалении.
Зачем занимать память? Т.е вы предлагаете как-то помечать их при их отключении? К примеру устанавливать значение поля isDead=true?

Еще поверх всего этого работает таймер который проверяет не мертва ли сессия. Ведь бывает так что связь оборвалась а Socket думает что все в норме и событие отключение не происходит. По этому каждые несколько минут в событии этого самого таймера происходит пометка каждой сессии. Устанавливается поле isAlive=flase. Если же клиент жив(обменивается данными), то он в функции получения данных ставит этот isAlive=true... Если же при следующем срабатывании таймера это занчение так и осталось false значит эту самую сессию нужно удалить из списка и сделать соотвествующую запись в БД. Так же все еще живому его партнеру нужно сообщить что он мертв. Потом естественно при отсутсвии ссылки на объект его уберет GC и памяти.

BlazkowiczДа. Помечать и удалять.


Ну почему бы не удалить его сразу? Т.е вы предлагаете удалить его по таймеру. Который будет временами пробегать по списку и удалять помеченные? Но где гарантия что в процессе удаления не произойдет проблем? Какой-то поток в этот момент будет производить перебор...

GorloPavel,

И могу ли я использовать foreach? Или лучше так...?

Blazkowicz Зачем это всё, если после комутации клиенты могут работать напрямую без сервера?
Как? Соединение такого типа SERVER(серый ip)<---->HUB SERVER<---->КЛИЕНТ.

BlazkowiczGorloPavelНу почему бы не удалить его сразу?
Откуда удалить?
Из общей коллекции тогда :
- не понятно что делать с итераторами, когда структура коллекции поменялась
- не понятно что делать с итераторами, которые только что приняли этот элемент за живой
Если использовать CopyOnWrite, то вообще из snapshot-а никак не удалить.
Чего вы добьетесь своим "удалением сразу"

GorloPavelТ.е вы предлагаете удалить его по таймеру.
Какой ещё таймер? Я предлагаю удалить его в любой подходящий момент.

GorloPavelКоторый будет временами пробегать по списку и удалять помеченные?
CopyOnWrite удалит немедленно, кроме тех потоков, которые в данный момент итерируются. Зачем таймер?


GorloPavelНо где гарантия что в процессе удаления не произойдет проблем?
О каких проблемах речь? Я вам объясняю, что никакая синхронизация вам не гарантирует что не валидый конекшн не будет использован. Соединение может умереть сразу же как только вы выйдете из блока синхронизации и начнете его использовать. Поэтому бороться с невалидным соединением нужно на уровне его использования, а не итерации по списку.

Неужели все не так как я думаю?


Список_1:
1
2
3
4

Поток #1:

Блокируем_список(Список_1)
Удаляем элемент номер 2

Разблокируем_список(Список_1)

Поток #2
Блокируем_список(Список_1)
Читаем список - элемент номер 1

Ну и наоборот... Я не прав?

Каждый поток ждет пока его освободит другой... Нельзя такое?

BlazkowiczКакой ещё таймер? Я предлагаю удалить его в любой подходящий момент.


Какой такой момент? Тысячи пользователей работают... Подключаются и отключаются. Вы представляете что будет если на каждую сессию будет выделятся хотя бы 512кб ОЗУ?

Blazkowicz,

Получается что неразрешимая задача?

Blazkowicz NAT Punch-Through. Вы их так и не осилили?
Когда вы приводили мне эти ссылки?

BlazkowiczGorloPavelКакой такой момент? Тысячи пользователей работают... Подключаются и отключаются. Вы представляете что будет если на каждую сессию будет выделятся хотя бы 512кб ОЗУ?
snapshot массива это только массив ссылок, а не полная глубокая копия. 4 байта на элемент. Вряд ли у вас будет более 1к постоянных, клиентов. Это 4к на поток. Пусть даже 1000 потков, это всего 4Мб. Если вы выжмете из сервера нагрузку в 1К клиентов и 1К потоков, что, мне кажется, маловероятным, то CopyOnWrite отожрет максимум 4Мб, а в реальности намного меньше.

В данный момент более 4к.

Ок. Действительно. А что если их просто помечать как вы советовали. Ну и пусть они висят. А по таймеру блочить этот лист к примеру раз в 20 секунд чистить... ну а потом пусть все читают дальше... Ну а если будут проблемы с производительностью или памятью, то можно уменьшать или увеличивать таймер очистки. Как вы думаете?

Blazkowicz,

2 ядра 2 гига. Занято всего ~800 метров ОЗУ.

Blazkowicz,

К сожалению NAT Punch-Through как я понял нормально работает только с UDP.

Blazkowicz,

Ну как не более... Кол-во растет. Т.е вы хотите сказать что при >4000 сокет-потоков при том что каждый будет работать с этим листом CopyOnWrite будет занимать не более мегабайта ОЗУ? И еще... Я немного не понял про CopyOnWrite... Не получится так, что один поток уже удалил элемен, а другой имеет копию листа с неудаленным элементом и будет расценивать его как живой?

Blazkowicz Но, как я уже несколько раз писал выше, это не критично.

Ну как же не критично? Ведь при переборе объектов один клиент может с коммутироваться с другим, которого уже нет!