Есть один поток-читатель и n потоков-писателей, которые постояно вызываются через опеределенный промежуток времени.
Имется грубо говоря вектор целых чисел, где каждый элемент соответсвует одному писателю. То есть на скольк я понимаю синхронизировать запись не требуется, потому что писатели гарантировано пишут в разную память?
Время от времни, я хочу забирать эти числа. Вот как мне блокировать писателей? Если это делать на одном мьютексе, тогда писатели будут блокировать еще друг друга, хотя они вполне могут писать одновремено.
Да еще надо учитывать, что бы i-ый писатель на j+1 запуске, не начал заполнять i-ый элемент вектора, пока не закончилась j-ый запуск. ну это можно сделать, если на каждый элемент вектора завести свои мьютекс.

Надеюсь более менее понятно описал.

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

_>Есть один поток-читатель и n потоков-писателей, которые постояно вызываются через опеределенный промежуток времени.
_>Имется грубо говоря вектор целых чисел, где каждый элемент соответсвует одному писателю. То есть на скольк я понимаю синхронизировать запись не требуется, потому что писатели гарантировано пишут в разную память?
_>Время от времни, я хочу забирать эти числа. Вот как мне блокировать писателей? Если это делать на одном мьютексе, тогда писатели будут блокировать еще друг друга, хотя они вполне могут писать одновремено.
_>Да еще надо учитывать, что бы i-ый писатель на j+1 запуске, не начал заполнять i-ый элемент вектора, пока не закончилась j-ый запуск. ну это можно сделать, если на каждый элемент вектора завести свои мьютекс.


Может быть так же при чтении тупо блокировать каждый мьютекс для каждого потока?

_>Надеюсь более менее понятно описал.

Таки переспрошу. Имеются n писателей и 1 читатель. Писатели пишут в vector<int>, причем у каждого писателя в нем своя ячейка. Размер вектора равен ровно n и не меняется. Читатель читает из произвольных ячеек. Правильно?

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

_>>Надеюсь более менее понятно описал.

AL>Таки переспрошу. Имеются n писателей и 1 читатель. Писатели пишут в vector<int>, причем у каждого писателя в нем своя ячейка. Размер вектора равен ровно n и не меняется. Читатель читает из произвольных ячеек. Правильно?

Ага

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

_>>Надеюсь более менее понятно описал.

AL>Таки переспрошу. Имеются n писателей и 1 читатель. Писатели пишут в vector<int>, причем у каждого писателя в нем своя ячейка. Размер вектора равен ровно n и не меняется. Читатель читает из произвольных ячеек. Правильно?

Единственное, что число потоков-писателей(пул писателей) может быть в какой то момент времени больше > n:
на i-ячеику могут быть нацелено несколько потоков.

AL>>Таки переспрошу. Имеются n писателей и 1 читатель. Писатели пишут в vector<int>, причем у каждого писателя в нем своя ячейка. Размер вектора равен ровно n и не меняется. Читатель читает из произвольных ячеек. Правильно?
_>Ага

Тут возможны свои проблемы: при доступе к памяти по соседним адресам позникает неявная блокировка.
Т.е. если сделать вектор не из int а из структур размером не меньше линейки кэша, быстродействие поднимется.
Даже если потребуется пожертвовать частью памяти на выравнивание.

см. http://www.ddj.com/architect/208200273?pgno=3

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

_>Есть один поток-читатель и n потоков-писателей, которые постояно вызываются через опеределенный промежуток времени.
_>Имется грубо говоря вектор целых чисел, где каждый элемент соответсвует одному писателю. То есть на скольк я понимаю синхронизировать запись не требуется, потому что писатели гарантировано пишут в разную память?
_>Время от времни, я хочу забирать эти числа. Вот как мне блокировать писателей? Если это делать на одном мьютексе, тогда писатели будут блокировать еще друг друга, хотя они вполне могут писать одновремено.

Возьми rw-lock и договорись, что твои писатели — это "читатели" (потому что они друг на друга не влияют), а твой читатель — это "писатель" (потому что он влияет на всех).
Вот и вся сказка

_>Да еще надо учитывать, что бы i-ый писатель на j+1 запуске, не начал заполнять i-ый элемент вектора, пока не закончилась j-ый запуск. ну это можно сделать, если на каждый элемент вектора завести свои мьютекс.

Ну уж каждый писатель-то сам в себе последователен как поток? Или за его псевдонимом прячется толпа литературных негров?

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

К>Возьми rw-lock и договорись, что твои писатели — это "читатели" (потому что они друг на друга не влияют), а твой читатель — это "писатель" (потому что он влияет на всех).
К>Вот и вся сказка

ух, спасибо.

К>Ну уж каждый писатель-то сам в себе последователен как поток? Или за его псевдонимом прячется толпа литературных негров?
Сам поток поседователен.
Просто через некоторый промежуток времени будет запущен еще один идентичный поток, а гарантии что первый закончил работу нет ж.

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

_>Есть один поток-читатель и n потоков-писателей, которые постояно вызываются через опеределенный промежуток времени.
_>Имется грубо говоря вектор целых чисел, где каждый элемент соответсвует одному писателю.

Я может чего не догнал — писателям обязательно обращаться к своим данным через вектор[j]?

По-идее, делаешь вектор с указателями на данные. Каждый писатель получает указатель на свои данные. Про чужие данные он теперь железно ничего не знает.

Модификация вектора не влияет на работу текущих писателей.

Что-то типа того...

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

К>Возьми rw-lock и договорись, что твои писатели — это "читатели" (потому что они друг на друга не влияют), а твой читатель — это "писатель" (потому что он влияет на всех).
К>Вот и вся сказка

Сдается мне, в изначальной постановке, когда размер вектора равен кол-ву писателей, на однопроцессорной системе специальные меры вообще не нужны, поскольку int можем писать/читать "атомарно" по отношению к другому писателю/читателю. Ну, разве что снабдить вектор семафором, который будут постить писатели, а читатель будет на нем ждать.

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

AL>Сдается мне, в изначальной постановке, когда размер вектора равен кол-ву писателей, на однопроцессорной системе специальные меры вообще не нужны, поскольку int можем писать/читать "атомарно" по отношению к другому писателю/читателю. Ну, разве что снабдить вектор семафором, который будут постить писатели, а читатель будет на нем ждать.

Просто у читателя будет каша в векторе.
Хотя, если так подумать: если нам не нужен точный момент защёлкивания вектора, то можно отделаться атомарным доступом к каждому элементу.
От одно/много-процессорности здесь ничего не зависит, просто вместо голого доступа нужно использовать соответствующие апишные функции — InterlockedXXXX или что там в вашей любимой ОС.

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

КД>По-идее, делаешь вектор с указателями на данные. Каждый писатель получает указатель на свои данные. Про чужие данные он теперь железно ничего не знает.
КД>Модификация вектора не влияет на работу текущих писателей.

Зато теперь придётся синхронизировать каждого писателя с читателем.
Заводить кучу мьютексов? Расточительно. Кучу сокетов, очередей сообщений, и т.п. синхронизированных средств обмена? Ещё расточительнее.

Поэтому или дешёвый lock-free регистр, или общий для всех писателей rw-lock.
При этом логика будет разная.
В зависимости от того, что нужно топикстартеру, можно выбирать.

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

К>Просто у читателя будет каша в векторе.
К>Хотя, если так подумать: если нам не нужен точный момент защёлкивания вектора, то можно отделаться атомарным доступом к каждому элементу.
К>От одно/много-процессорности здесь ничего не зависит, просто вместо голого доступа нужно использовать соответствующие апишные функции — InterlockedXXXX или что там в вашей любимой ОС.

Если в массив (в заготовленный вектор) кладется значение вот так:

writers_bins[writer_num] = writer_value;

а читается так:

int val = writers_bins[idx];

то разве там будет каша? Ведь int нельзя записать/прочитать не целиком, поэтому писатели могут вытеснять друг друга и читателя в любой момент. От кол-ва процессоров действительно ничего не зависит.

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

AL>то разве там будет каша? Ведь int нельзя записать/прочитать не целиком, поэтому писатели могут вытеснять друг друга и читателя в любой момент. От кол-ва процессоров действительно ничего не зависит.

Каша не в отдельном элементе, а в их совокупности.

Скажем, писатели валят в вектор данные с разных датчиков.
Ровно в полночь читатель говорит всем "стоп" и вытаскивает всё, что датчики наделали до полуночи.
А если не защёлкнуть, то можно получить и заполночные данные.

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

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

К>Так что нужно посмотреть на систему целиком, а не на единственное её место вокруг этого вектора.

Да система выглядит простенько. Примерн так
Есть n датчиков каждый из которых через опеределенный промежуток времени отправлояет данные на сервер.
На сервере пул потоков обслуживает все датчики: записывает принятые числа в вектор.
Как только есть полный комплект данных (от всех датчиков есть числа), данные извлекаются и отправляются дальше.
И вектор снова освобождается для записи.

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

_>Здравствуйте, Кодт, Вы писали:

К>>Так что нужно посмотреть на систему целиком, а не на единственное её место вокруг этого вектора.

_>Да система выглядит простенько. Примерн так
_>Есть n датчиков каждый из которых через опеределенный промежуток времени отправлояет данные на сервер.
_>На сервере пул потоков обслуживает все датчики: записывает принятые числа в вектор.
_>Как только есть полный комплект данных (от всех датчиков есть числа), данные извлекаются и отправляются дальше.
_>И вектор снова освобождается для записи.

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

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

К>Каша не в отдельном элементе, а в их совокупности.
К>Скажем, писатели валят в вектор данные с разных датчиков.
К>Ровно в полночь читатель говорит всем "стоп" и вытаскивает всё, что датчики наделали до полуночи.

Это кейс справедлив, когда читателю требуется когерентность данных от разных источников. Иными словами, когда весь вектор рассматривается, как одно "данное". Однако такой постановки не было (специально переспросил), иначе бы пришлось городить вокруг "вектора" доп. обвязку (скажем, на atomic add/swap и двух семафорах) плюс задавать дополнительные вопросы.

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

_>Да система выглядит простенько. Примерн так
_>Есть n датчиков каждый из которых через опеределенный промежуток времени отправлояет данные на сервер.
_>#1 На сервере пул потоков обслуживает все датчики: записывает принятые числа в вектор.
_>#2 Как только есть полный комплект данных (от всех датчиков есть числа), данные извлекаются и отправляются дальше.
_>#3 И вектор снова освобождается для записи.

Опять не понял. А нифига тогда нужен в пункте #1 вектор?

— Пришли данные от датчика
— Берем свободный поток и скармливаем ему эти данные.
— После обработки, поток отдает результат дальше, где уже формируется твой любимый вектор.

А читатель что делает с вектором? Тупо проверяет (грубо говоря), что все N элементов были обработаны и его можно передавать дальше?

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

_>Разумется, если первый датчик к примеру уже три раза презапишет свои данные, а второй первый раз — данные все равно валидны.

Представим себе такую ситуацию

С блокировкой

писатели
|  |  |
#  |  |
|  #  |
|  |  #
|  #  #
+......
.\ .  .
. \.  .
.  +  .
.  .\ .
.  . \.
......+-- читатель забрал набор (в это время писатели заблокированы)
#  #  |   писатели разблокировались и записали всё то, что у них скопилось

Без блокировки

|  |  |
#  |  |
|  #  |
+  |  #  набор готов
|\ #  |
| \|  #
#  +  |
|  |\ |
|  # \|
|  |  +-- читатель медленно выгреб

Разница между ними лишь в тонкостях "фотофиниша".
Если поток-писатель успеет пролезть с новыми данными до того, как читатель проснётся — ему повезло. Не успеет — запишет уже в следующий раз.
Из-за этого сложно говорить о когерентности.

А раз так — зачем нужно блокировать?

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

AL>>>Таки переспрошу. Имеются n писателей и 1 читатель. Писатели пишут в vector<int>, причем у каждого писателя в нем своя ячейка. Размер вектора равен ровно n и не меняется. Читатель читает из произвольных ячеек. Правильно?
_>>Ага

K13>Тут возможны свои проблемы: при доступе к памяти по соседним адресам позникает неявная блокировка.
K13>Т.е. если сделать вектор не из int а из структур размером не меньше линейки кэша, быстродействие поднимется.
K13>Даже если потребуется пожертвовать частью памяти на выравнивание.

K13>см. http://www.ddj.com/architect/208200273?pgno=3

+1