Всем привет...

Вроде почитал предыдущие опусы, джавадоку листнул...

Но как-то недовъехал....

Придётся ли дописывать под себя...

Суть вопроса:

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

Причём взаимные локи ридов надо исключить.


java.util.concurrent.CopyOnWriteArrayList подойдёт?
Я так понял, при обращении рида, он будет считывать и, если начнётся write - дочитает со своей копии.
И только при следующем обновлении считает новое значение.


Ещё есть нюанс - рид проверяет валидность записи - если всё плохо - инициализирует write.
Если придут много ридов, увидят что запись плоха и паралелльно инициализируют write... В общем, этого надо избежать 

Без флажков не обойтись? или... ?

Добавлено @ 12:56 
Да... ещё... 

Чтоб исключить 
если проверку

на невалидность записи синхронизировать в один блок с врайтом - тогда множества паралелльных write'ов можно избежать, имхо...
Но! Тогда в нормальном рабочем режиме READ'ы будут локать друг друга на этой проверке 

Зачем ридерам блокировать друг друга если они ничего не меняют, а просто читают информацию?

Нельзя ли просто во время изменения коллекции использовать synchronized(коллекция)?

Стоп... Ридерам тоже синхронизированно считывать с врайтером.
Если во время изменения поставить синхро, а в это же время риды без синхро будут читать как захотят... и пофиг им будет, что кто-то изменяет... Или я промахнулся?

У вас модификация - замена элемента, т.е.  операция присвоения. Если считать эту операцию атомарной, то никакой синхронизации не надо, потому что невозможна ситуация, когда райтер наполовину вписал ссылку на новый обьект и остановился, а ридер пытается по этой недописанной ссылке получить доступ к обьекту. 

 я попробовал код в котором в synchronized() ставится код writer-a, а код reader-a не использует synchronized() - не работает.  сорри.

Я думаю надо код и writer-a и reader-a ставить в synchronized(), но не весь. у reader-a только саму операцию чтения и все. (только коллекция.дайЭлемент()) (да и у writer-a впринципе можно только операцию помещения элемента в коллекцию поместить в synchronized()) Хоть и будет блокировка, но думаю вполне приемлемая.    

Проскакивала эта мысль...
Действительно... 

Ещё один нюанс....

Если несколько тредов находят что запись устарела и запускают write:

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

Неплохо бы сделать так, чтоб только первый подтягивал... 
но тогда все остальные, "пришедшие после него", должны вместо собственного обновления, ждать того первого... тут бы не помешало их как-то остановить...
Выходит, нужен флаг "обновляю", остальные натыкаются и ждут обновления...

Как бы попроще так?

Т.е. как я понял тебе надо нечто вроде select for update, да?

Как раз этого хочу избежать...
Можно всё синхронизировать - ридер залез, заблокировал, проверил, если надо, обновил, вышел.
Последующие даже не узнают, что он обновлял.
Но нормальный рабочий режим - тысячи ридов без врайта... и вот как раз хочу избежать ЛЮБЫХ блокировок без райта :-/

Стоп!
А кто что может сказать насчёт фичи java.util.concurrent:



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

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


 А writer - должен ставить writelock он может быть только один и будет ждать пока все readlock-и освободятся

Нет. Нужен кэш 

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

Добавлено @ 15:56 

Зачем их тогда вообще ставить? Что они будут блокировать?


Ага.. понял... чтоб не начали обновлять, пока все не дочитают...
А будут ли потом риды терпеливо ждать снятия writelock ?

будут;

http://java.sun.com/j2se/1.5.0/docs/api/ja...dWriteLock.html

Зачем тебе щеколда? Тебе достаточно простого lock.tryLock(). Проблема только в том, что тебе придется создать еще один список с Lock-ами, или HashMap. А это может потребовать лишних расходов памяти и синхронизации (для HashMap).

А зачем давать право на апдейт ридерам? Ридер должен рид. А следить за свежестью осетрины назначить толкового майора - отдельный поток. Может все упростится?

Если майор не успеет обновить данные, то читатели скушают несвежую осетрину. А если никто не будет обедать двое суток, то майор понапрасну будет вылавливать и вылавливать новую осетрину.

Что-то вроде такого справится?


То есть синхронизировать будем на уровне записи, лок хранится тоже в записи, хэшмап о таких ужастях даже не знает...
При обновлении просто подкидывается новый(другой) рекорд в РекордВизМэп.


Но вот.... если приходит поток - читает... а такого рекорда у нас ещё нету... - начинает подтягивать...
И тут второй начинает то же самое делать...

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