Сообщение Re[2]: Вопрос по synchronized от 25.10.2023 17:10
Изменено 25.10.2023 17:25 pva
Re[2]: Вопрос по synchronized
Здравствуйте, GarryIV, Вы писали:
благодарю за ответ.
Смысл первого вопроса не в чистоте кода, а в разнице использования
pva>>Правильно ли я понимаю что для синхронизированных коллекций коллекция будет лочится на все время цикла для обеспечения целостности итераторов?
GIV>нет не будет
хм.. то есть, вполне реально огрести рантайм эксепшн о том что идет доступ к измененной коллекции из-за инвалидации итераторов?
GIV>оно конечно решит проблему ( как и synchronized (this.numbers) )
GIV>но в жабе есть конкурентные коллекции же примерно 100 лет как.
Да я как-то проспал революцию. А последний раз, когда я заглядывал в рукводоства по стандартным конкурентным коллекциям, там отсутствовали то ли очереди, то ли еще какие-то стандартные коллекции.
Кстати, в конкурентных коллекциях нет проблем с классическими циклами (типа инвалидации как в вопросе выше)?
И помнится там что-то мудрили с пайпингом, навроде Collection.forEach(...). Хотя может это не из той оперы.
благодарю за ответ.
Смысл первого вопроса не в чистоте кода, а в разнице использования
final private Object lock = new Object();
final private List<...> collection = new LinkedList<>();
synchronized(this.lock) { collection.add(); }
и варианте без "Object lock", когда объектом синхронизации выступает сама коллекция.pva>>Правильно ли я понимаю что для синхронизированных коллекций коллекция будет лочится на все время цикла для обеспечения целостности итераторов?
GIV>нет не будет
хм.. то есть, вполне реально огрести рантайм эксепшн о том что идет доступ к измененной коллекции из-за инвалидации итераторов?
GIV>оно конечно решит проблему ( как и synchronized (this.numbers) )
GIV>но в жабе есть конкурентные коллекции же примерно 100 лет как.
Кстати, в конкурентных коллекциях нет проблем с классическими циклами (типа инвалидации как в вопросе выше)?
И помнится там что-то мудрили с пайпингом, навроде Collection.forEach(...). Хотя может это не из той оперы.
Most concurrent Collection implementations ... in that their Iterators and Spliterators provide weakly consistent rather than fast-fail traversal...
Re[2]: Вопрос по synchronized
Здравствуйте, GarryIV, Вы писали:
благодарю за ответ.
Смысл первого вопроса не в чистоте кода, а в разнице использования
pva>>Правильно ли я понимаю что для синхронизированных коллекций коллекция будет лочится на все время цикла для обеспечения целостности итераторов?
GIV>нет не будет
хм.. то есть, вполне реально огрести рантайм эксепшн о том что идет доступ к измененной коллекции из-за инвалидации итераторов?
GIV>оно конечно решит проблему ( как и synchronized (this.numbers) )
GIV>но в жабе есть конкурентные коллекции же примерно 100 лет как.
Да я как-то проспал революцию. А последний раз, когда я заглядывал в рукводоства по стандартным конкурентным коллекциям, там отсутствовали то ли очереди, то ли еще какие-то стандартные коллекции.
Кстати, в конкурентных коллекциях нет проблем с классическими циклами (типа инвалидации как в вопросе выше)?
И помнится там что-то мудрили с пайпингом, навроде Collection.forEach(...). Хотя может это не из той оперы.
благодарю за ответ.
Смысл первого вопроса не в чистоте кода, а в разнице использования
final private Object lock = new Object();
final private List<...> collection = new LinkedList<>();
synchronized(this.lock) { collection.add(); }
и варианте без "Object lock", когда объектом синхронизации выступает сама коллекция.pva>>Правильно ли я понимаю что для синхронизированных коллекций коллекция будет лочится на все время цикла для обеспечения целостности итераторов?
GIV>нет не будет
GIV>оно конечно решит проблему ( как и synchronized (this.numbers) )
GIV>но в жабе есть конкурентные коллекции же примерно 100 лет как.
Да я как-то проспал революцию. А последний раз, когда я заглядывал в рукводоства по стандартным конкурентным коллекциям, там отсутствовали то ли очереди, то ли еще какие-то стандартные коллекции.
И помнится там что-то мудрили с пайпингом, навроде Collection.forEach(...). Хотя может это не из той оперы.
Most concurrent Collection implementations ... in that their Iterators and Spliterators provide weakly consistent rather than fast-fail traversal...