Здравствуйте, VladD2, Вы писали:

VD>О чем ты? Это всего лишь создание дефолтного компаратора. Ну, создадут его (в вырожденном случае) 3 раза параллельно и что? Все равно они одинаковые.
VD>И на скорость это тоже влиять не будет. Так как создаются компораторы по одному для типа.
Меня не это беспокоит.

WH>>ИМХО межу этими строками нужен барьер памати
WH>>

WH>>            defaultComparer = Comparer<T>.CreateComparer();
WH>>            //вот тут
WH>>            Comparer<T>.defaultComparer = defaultComparer;
WH>>

WH>>[/паранойя]
VD>Зачем?
За тем что второй поток может увидеть указатель на компатор до того как тело компатора приедит к нему.
Для того чтобы гарантировать что второй поток полностью увидит тело компатора нужен барьер памяти.

VD>Понятно. Но красно-черное дерево автоматически барансируется и у него относительно дешёвое обновление.
Дело в том что красно-черное дерево это по сути извращенная форма 2-3 дерева.
В свою очередь 2-3 дерево это частный случай B-дерева.
А с балансировкой у B-деревьев все в порядке.
Плюс в том что 2-3 деревья плодят меньше объектов и требуют меньше вычислений при вставке.
Короче вскрытие покажет кто быстрее.

VD>И вообще это уже выливается в новую структуру данных. Трудозатрат будет намного больше чем просто поправить имеющуюся реализацию.
Ну хочется мне 2-3 дерево написать. Тебе жалко что-ли?
Вставку уже написал. Сейчас думаю как удаление сделать красиво и эффективно.

VD>Это ты о Sum(), Subtract(), Intersect() и Xor() говоришь?
VD>Там второй Set рассматривается как просто список. Так что проблем быть не должно.
При наивной реализации.
Но если действовать не в лоб, а используя свойства контейнера то можно и побыстрее... но будут проблемы с разными компаторами.