Касательно п.1, то изначально был набросок варианта с использованием HashSet'а с целью вычисления повторяющегося элемента, вычисляемого выводом метода add, мол "заливать в Set либо до next==null, либо до add-->false.
предположительно, у нас есть класс, принимающий объекты тематики "список"(аля реализующий интерфейс OneWayList). При этом заранее неизвестно что именно это за реализация - конечная\замкнутая. Отсюда нужно сделать соответствующие телодвижения по определению "с чем имеем дело".
Правда это всё в рамках моих догадок касательно заданного текста задачи.
Николай Павлов: да вот самому интересна "среда" использования подобного списка. Предполагаю вариант, где существует объект обработчик, который принимает на вход контейнеры, и занимается последующим взаимодействием с ним. Если правильно продумать момент приема объекта списка, то думаю можно обыграть сам момент последующего обращения. Было бы проще, если бы на старте стояло условие "список с элементами", то тут на стадии приема уже можно было без проблем определить "конечную точку".
Касательно вопроса "хода рассуждений", то пожалуй вы правы, ибо предыдущие задачи, где данная задача является последней в списке, имели в себе контекст более на наличие мышления нежели на знания каких-то тонкостей языка.
Николай Павлов: насколько я понял логику подобных списков, то, при условии, что в this.next вписывается значение head.next, после чего уже идет обновление head.next на this, реферал на начальный элемент
должен был бы быть чем-то сталым, и применять к нему volatile нет нужды. Можно было бы разбить саму процессию на этап определения зацикленности списка, попутно его заблокировав для спокойного выполнения проверки и определения точки конца списка, будь то head.next = null, либо head.next = firstElem. А дальше, при выполнении последующих операций по извлечению элементов делать проверку типа while(head.next != firstElem).
Если я ничего не напутал, то мы получим и нормальную проверку списка, и сможем спокойно оперировать с последующими операциями со списком.
UA3MQJ: хм. А согласно определению википедии, односвязный список имеет характеристику к-ва элементов. Тоись на этапе считывания какбы можно пойти путем пересчета рефералов next. Правда по к-ву шагов, с учетом того, что конструкция может двигаться в момент проверки, это будет эквивалентным. Да и к-во элементов - весч не сталая, а значит начав с 40 элементов, на середине пробежки их может оказаться 30, и... приехали.
Николай Павлов: вариант с двумя итераторами был отвергнут, аргументируя это тем, что проверка должна выполняться "на ходу", без остановки работы других потоков. Я конечно понимаю, что работа с псевдозацикленным списком должна была бы выполняться с осознанием этого факта, но имеем что имеем.
А разве при удалении ссылок не благоприятным будет факт "упирания" в null?
Касательно второго варианта. А что, если "извернуться" и в методе получения элемента списка пустить
один итератор, который будет выполнять сравнение текущей ячейки с next?
А можно поподробнее касательно 3го варианта? Что он из себя представляет?
Вариант конечно, но по подсчету шагов можно и просто при каждом вызове метода получения элемента
делать проверку, прогоняя по циклу аля while(next!=null), с целью упереться либо в стену null, либо всетаки получить next==this, но незнаю насколько этот подход "гуманен".
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.