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

IB>Это что меняет суть вопроса? Зачем метод AcquireLocks для эксклюзивной блокировки (если она действительно эксклюзивная, как утверждает samius), если эксклюзивную блокировку можно написать как Monitor.Enter(_syncObject)?
Она действительно эксклюзивная, даже если вызывается внутри метода AcquireLocks. Читайте документацию Monitor.Enter.

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

IB> Зачем метод AcquireLocks для эксклюзивной блокировки (если она действительно эксклюзивная, как утверждает samius), если эксклюзивную блокировку можно написать как Monitor.Enter(_syncObject)?

Так захватить-то нужно те же локи, что используются при частичной блокировке. Просто все.

S>Расширение BCL для своего алгоритма? Интересно. А что такого может понадобиться от BCL, чего нельзя написать самому?

То что потребуется в алгоритме, но для чего не будет явной реализации в BCL. Это к тому что
S>Сомневаюсь что есть какое-то доказательство для текущего кода из BCL.
Если нет для текущего значит, нужно расширить. А чтобы понять какие расширения нужны, нужен алгоритм.
Хотя действительно вряд ли расширения понадобятся. При реализации словаря ничего такого сложно плохо формализуемого из BCL понадобиться не должно, только базовые структура данных и операции. Вот что может понадобиться, так это разработка математической теории под это дело, или расширение существующих. Но я не уверен, не специалист. Наверняка параллельные алгоритмы должны быть хорошо изучены. Поэтому я и говорю, это сложная научная задача, судя по тому что других сторонних реализаций нет ни одной. Я по крайней мере не встречал.

IB>>Это что меняет суть вопроса? Зачем метод AcquireLocks для эксклюзивной блокировки (если она действительно эксклюзивная, как утверждает samius), если эксклюзивную блокировку можно написать как Monitor.Enter(_syncObject)?
S>Она действительно эксклюзивная, даже если вызывается внутри метода AcquireLocks. Читайте документацию Monitor.Enter.

Конечно можно внутри AcquireLocks вызвать Monitor.Enter(_syncObject). Но метод называется AcquireLocks, а не AcquireExclusiveLock. Могу предположить, что в итоге действительно получается некая эксклюзивная блокировка, только не на уровне всего экземпляра класса, а на каком-то другом, более узком уровне для увеличения выгоды от увеличения числа потоков.

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

S>>Расширение BCL для своего алгоритма? Интересно. А что такого может понадобиться от BCL, чего нельзя написать самому?

IB>То что потребуется в алгоритме, но для чего не будет явной реализации в BCL. Это к тому что
S>>Сомневаюсь что есть какое-то доказательство для текущего кода из BCL.
IB>Если нет для текущего значит, нужно расширить. А чтобы понять какие расширения нужны, нужен алгоритм.
google-> lockfree hashtable

IB>Поэтому я и говорю, это сложная научная задача, судя по тому что других сторонних реализаций нет ни одной. Я по крайней мере не встречал.
Я думаю что скорее это никому не надо.

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

S>>Она действительно эксклюзивная, даже если вызывается внутри метода AcquireLocks. Читайте документацию Monitor.Enter.

IB>Конечно можно внутри AcquireLocks вызвать Monitor.Enter(_syncObject). Но метод называется AcquireLocks, а не AcquireExclusiveLock. Могу предположить, что в итоге действительно получается некая эксклюзивная блокировка, только не на уровне всего экземпляра класса, а на каком-то другом, более узком уровне для увеличения выгоды от увеличения числа потоков.

Я вам об этом и написал ранее. Только GrowTable берет действительно эксклюзивную, т.к. передает всегда один и тот же индекс — 0.

P>Так захватить-то нужно те же локи, что используются при частичной блокировке. Просто все.
Точно! только можно было ReadWriteLock использовать.

private ReadWriteLock _exclusiveReadWriteLock;

Частичные блокировки запрашивают _exclusiveReadWriteLock.AcquireReaderLock, а для в реализации AcquireLocks тогда просто _exclusiveReadWriteLock.AcquireWriterLock

S>google-> lockfree hashtable
Ну и где хоть одна реализация для NET?
То что что такие структуры данных не нужны никому сомневаюсь, количество ядер на процах давно перевалило за 1.

Хотя с таким подходом будет медленнее чем у них

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

S>>google-> lockfree hashtable
IB>Ну и где хоть одна реализация для NET?
Вы спросили про алгоритм, я ответил именно на это.

IB>То что что такие структуры данных не нужны никому сомневаюсь, количество ядер на процах давно перевалило за 1.
Никому из дотнетчиков не нужны настолько что бы писать свою реализацию для дотнета.
Может и написал кто, да не выложил.
Да я и не очень представляю, за счет чего должен быть выигрышь в куче потоков. Там же RMW операции, они долгие по своей природе. В десятки (или более) раз тормознее обычных на кэше.

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

Вообще для улучшения производительности, можно Хэш таблицу Разделить например на 1) хэш таблиц. Учитывая что данных будет много.
Тогда Доступ к каждой можно сделать как поз=Хэш % 10. Если хэши хорошо перемешаны вероятность доступа из двух потоков к одной хэш таблицы будет как 1/10, и соответсвенно уменьшится время ожидания на вставку изменения.

IB>Хотя с таким подходом будет медленнее чем у них

А может и нет, наверное это долго много раз вызывать Monitor.Enter()
Может быстрее будет _exclusiveReadWriteLock.AcquireWriterLock

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

IB>

IB>lock (dictionary)
IB>{
IB>    dictionary.Add(key, value);
IB>}
IB>

IB>и


IB>

IB>concurrentDictionary.TryAdd(key, value);
IB>

IB>Здесь однозначно побеждает СoncurrentDictionary.

Правильно, и это именно то ради чего нужен СoncurrentDictionary.

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

IB>Даже на 8 ядерном процессоре Dictionary на одном потоке быстрее, чем ConcurrentDictionary на 8 потоках.

Надо и remove добавить для полноты картины.

Как видно, время Add слабо меняется, а вот время Get меняется заметно. То есть, Get в ConcurrentDictionary работает быстрее !

Теперь сделай ровно тот же тест, но на большом количестве потоков для Dicionary с одновременными операциями add, remove, get — слив гарантирован.

I>Теперь сделай ровно тот же тест, но на большом количестве потоков для Dicionary

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

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

I>>Теперь сделай ровно тот же тест, но на большом количестве потоков для Dicionary

IB>Не для этого тест, я хочу выбрать делать ли мне многопоточный вариант или однопоточный.
IB>Тест показывает, что быстрее будет однопоточный.

А сценарии у тебя какие ? Итерации не нужны, удаление не нужно ?

IB>Здесь однозначно побеждает СoncurrentDictionary.
I>Правильно, и это именно то ради чего нужен СoncurrentDictionary.

Я не отрицаю, по Вашему мнению Ваша реплика что-то новое привносит?

I>А сценарии у тебя какие ? Итерации не нужны, удаление не нужно ?

Сценарий у меня добавить элементы в словарь за максимально короткое время

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

IB>Сценарий у меня добавить элементы в словарь за максимально короткое время
http://www.rsdn.ru/forum/dotnet/5177238.1

Автор: Serginio1
Дата: 22.05.13

S>Вообще для улучшения производительности, можно Хэш таблицу Разделить например на 1) хэш таблиц. Учитывая что данных будет много.
S>Тогда Доступ к каждой можно сделать как поз=Хэш % 10. Если хэши хорошо перемешаны вероятность доступа из двух потоков к одной хэш таблицы будет как 1/10, и соответсвенно уменьшится время ожидания на вставку изменения.

Если ключ был к примеру int, так можно было бы сделать.
К сожалению этот вариант для меня не подходит так тип ключа мне неизвестен, для меня он object.