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

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

S>>>1. Есть нехилый шанс отхватить деадлок.
H>>Пример ситуации приведи?
S>Одновременные операции над более чем одним элементом. Например:.

S>

S>Поток 1:
S>a+=b

S>Поток 2:
S>b+=a
S>

S>Чем сложнее объекты и чем больше между ними зависимостей — тем выше наши шансы

Да, все верно, но к сожалению ТС ничего о природе объектов и связях не рассказывает.

H>Да, все верно, но к сожалению ТС ничего о природе объектов и связях не рассказывает.
Не ТС, TS

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

H>>Да, все верно, но к сожалению ТС ничего о природе объектов и связях не рассказывает.
А>Не ТС, TS

Чем вам не нравится "топикстартер"?

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

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

HL>>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>>Если
HL>>Вот именно, что "если"...

PD>А что именно-то ? Время квантуется равными порциями для потоков одинакового приоритета. Играть с повышением приоритета самому — ясно, что будет иначе. А priority boost сам по себе не возникает. Так что все правильно.

Плюс спящий на примитиве синхронизации поток практически бесплатен для системы — так что, при спящих четырёх, пятый будет в самом деле работать быстрее в соло (с учетом, что все эти пять потоков привязаны на одно ядро).

А>Есть миллиард объектов с которыми работает 5 потоков. Читают из них, пишут в них.
А>Понятно, что создавать миллиарт ReadWrite lockов накладно. Лучше бы их было по числу потоков... Вобще как решаются данные задачи и нет ли каких-то наработок. Любые предложиния и варианты велком!

1. А если создавать объекты синхронизации когда они понадобяться и удалять когда никто к объекту не обращается? Можно какой нить пул организовать.

2. Если в объект добавить 4 байта, и замутить свою синхронизацию, накладно?

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

vf>1. А если создавать объекты синхронизации когда они понадобяться и удалять когда никто к объекту не обращается? Можно какой нить пул организовать.

vf>2. Если в объект добавить 4 байта, и замутить свою синхронизацию, накладно?
Да... к этому я и пришел пока...
А почему 4 байта? 2 бит вроде должно хватить?

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

vf>>1. А если создавать объекты синхронизации когда они понадобяться и удалять когда никто к объекту не обращается? Можно какой нить пул организовать.

ИМХО, это более универсальный подход. Хотя тут по памяти может и дороже выйти, смотря как-где объекты храняться... а указатели тоже имееют размер.

vf>>2. Если в объект добавить 4 байта, и замутить свою синхронизацию, накладно?
А>Да... к этому я и пришел пока...
А>А почему 4 байта?

Я то просто написал чтобы под Interlocked подходило.

А>2 бит вроде должно хватить?

Это зависит... 2 бита как-то маловато, один читатель — один писатель? По идее если читателей несколько, наверное для них нужен какой нить счетчик.

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

vf>Это зависит... 2 бита как-то маловато, один читатель — один писатель? По идее если читателей несколько, наверное для них нужен какой нить счетчик.

Наверное 3 бита для 5 потоков. А приостанавливать поток как, Sleep?! Не очень эстетично

А>В теории процессорное время делится равномерно между потоками, поэтому если 4 потока стоят, пятый работает быстрее(в идеале потери скорости нет).
А>Почему просто не использовать глобальный lock для всех объектов?
Может быть верно только для однопроцессорных машин. Но тогда и многопоточность, обычно, избыточна.

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

MD>Возьмите те же СУБД для примера. В таблице может быть милионо-милиард записей. Но два запроса смогут читать/писать её одновременно, при определенных условиях (мы говорим тут про блокировочники типа MS SQL, а не версионники а-ля Interbase). Возможность эта обусловлена тем, что блокировка в СУБД изначально ставится на страницу (группа из одной или более строк таблицы) — если два параллельно исполняемых запроса захотят данные, принадлежащие одной и той же странице, то "кто первым встал, того и тапки", второй ждёт. Если нет — то доступ будет тоже параллельным, т.к. каждый запрос работает со своей страницей/страницами данных. Лишь в самых тяжелых случаях СУБД расширяет блокировку до всей таблицы целиком.

MD>Т.е. Ваша задача — перепроектировать свою задачу так, чтобы она допускала разбиение всего множества объектов на страницы/пулы/etc — назовите как хотите. И чтобы синхронизация доступа шла на уровне этой страницы/пула/etc.
Вообще-то, RDBMS типа MS SQL умеют также работать с блокировками на уровне строки таблицы. Поэтому, перепроектирования задачи здесь не требуется.

Требуется сделать менеджер блокировок. Который не будет требовать предварительного создания отдельного объекта блокировки на каждый элемент коллекции.

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