Нужен List! Такие свойства:
Работают из 2-х потоков. В первом перечисляют все подряд и все. В это время во втором потоки происходит добавление или может быть даже удаление элемента. Добавляться должен асинхронно. Удаление. Если енумератор стоит на элементе который удаляется, то удаляющий поток лочится. Если енумератор уже прошел или еще не дошел до этого объекта, то объект удаляется. Ну и соответсвенно если объект удаляется и до него дошел енумератор то енумератор лочится, объект удаляется и енумератор идет дальне... Ну вобщем так.
Ибо нынешний List<> предполагает залочить всю коллекцию, перечислить, разлочится потом удалить. Что имхо не очень эффективно...

Здравствуйте, Аноним, Вы писали:

А>Нужен List! Такие свойства:
А>Работают из 2-х потоков. В первом перечисляют все подряд и все. В это время во втором потоки происходит добавление или может быть даже удаление элемента. Добавляться должен асинхронно. Удаление. Если енумератор стоит на элементе который удаляется, то удаляющий поток лочится. Если енумератор уже прошел или еще не дошел до этого объекта, то объект удаляется. Ну и соответсвенно если объект удаляется и до него дошел енумератор то енумератор лочится, объект удаляется и енумератор идет дальне... Ну вобщем так.
А>Ибо нынешний List<> предполагает залочить всю коллекцию, перечислить, разлочится потом удалить. Что имхо не очень эффективно...

Размер списка какой будет? Десяток элементов? Несколько сотен? Сто тыщ?

Здравствуйте, _FRED_, Вы писали:
_FR>Размер списка какой будет? Десяток элементов? Несколько сотен? Сто тыщ?
Очень большой. Даже в оперативке храниться не будет а прямо в файле на диске.

Здравствуйте, Аноним, Вы писали:

А>Очень большой. Даже в оперативке храниться не будет а прямо в файле на диске.
С такими требованиями проще взять in-memory dbms и не мучаться.

Вообще-то, с этого и надо было начинать.

Здравствуйте, Sinix, Вы писали:
S>С такими требованиями проще взять in-memory dbms и не мучаться.
А если помучаться?

Здравствуйте, Аноним, Вы писали:

S>>С такими требованиями проще взять in-memory dbms и не мучаться.
А>А если помучаться?
Для начала вам придётся изобрести способ вставлять/удалять значения в середину списка не смещая всё его содержимое. Дальше — правильный paging (хотя для начала сойдёт и memory-mapped file) и write-ahead log — чтоб не убить ваши бесценные данные банальным выдёргиванием вилки. Угадайте, что у нас получилось?

При таком подходе вас ждёт очень много переоткрытий

Здравствуйте, Sinix, Вы писали:
S>При таком подходе вас ждёт очень много переоткрытий
Но я про это не спрашиваю. Потому как уже изобрел. Я спрашиваю про List. Давайте предположим что он просто в оперативке лежит. чтобы не усложнять.
Дальше я сам разберусь. Итак в оперативке есть большой List в который асинхронно нужно вставлять, удалять данные. Пока меня интересует возможно ли это принципиально или здесь есть какой-то затык?
Опять же автор здесь делает не совсем эффективно при енумерации он лочит всю коллекцию и ее можно только читать...

Здравствуйте, Аноним, Вы писали:

_FR>>Размер списка какой будет? Десяток элементов? Несколько сотен? Сто тыщ?
А>Очень большой. Даже в оперативке храниться не будет а прямо в файле на диске.

А зачем тогда упоминать про List<>

Судя по тому, что было описано выше, вам подошёл бы связанный список: сделать удаление/добавление после определённого элемента и проход по списку из разных потоков должно быть не сложно.