(Форварднул с другого топика)

Давайте я предложу искусственную синтетическую постановку.

И вы увидете как ее невозможно просто сделать идеальной без цифр.

Даны две матрицы вещественных чисел. A и B. Одинаковой размерности. Их надо перемножить. По правилам
матриц. Тоесть первая стока матрицы A уможается почленно на столбец матрицы B. И вектор суммируется.
Результат записывается в элемент матрицы С. И так далее для всех комбинаций строки А и столбца B.

Шаблон кода на сях.





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


====

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

Какие будут предложения?

Самый простейший путь - распределением столбцов B между потоками.

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

Сделать алгоритм "кэш-дружелюбным" это отдельная задача, к многопоточности
отношения не имеющая. Решается предварительным транспонированием В.

Хорошая идея с транспонированием. Но с какого размера матриц? 10х10 надо транспонировать?

Правда не понимаешь? Ну вот в цикле обхода матрицы B мы несколько раз обходим ее "по столбцам".
Матрица - любого размера. Может быть 100х100. 1000х1000. Неважно.

А когда надо?

Спасибо. Данный пост является просто примером к родительскому топику. Примером того что
мы не сможем обсудить сферический лок в вакууме без дополнительных сведений. Быть может
без примера того как много потоков будут хотеть получить этот лок. И без описания типичного
железа. Что это? Серверный Xeon с 4-головами и 24 тредами? Или просто ней-то ноутбучик?

И без понимания полезной работы мы тоже не придумаем ничего. Вот если-бы зайчик
сказал что в каждом контейнере лежит например счетчик. Или JSon документ. Или матрица
чисел и мы что-то с ней будем делать - вот тогда и пойдут более полезные предложения.

Мы можем множить матрицы "слоями". Это естественным образом вытекает из самой формулы умножения.
Но какого размера брать слой?

Давай еще поговорим про жесткий синхронизм и спрведливость доступа.
Допустим внутри контейнера лежит string в котором - XML документ.
И работают с ним 10 Threads. Они - периодически захватывают контейнер
и что-то добавляют в документ. Возможно - обновляют.

Поскольку операция работы с XML-документом сложная и комплексная - его надо
парсить и сериализовать - то я вангую что время работы с документом будет порядка
нескольких милисекунд. Например 20 мс.

За эти 20 мс прочие 9 потоков могут встать в ожидание. Актуальный вопрос - кто первый получит
доступ? Технически - любой. Это не зависит от того кто кто раньше встал в монитор. Грубо говоря
у данного mutex нет fairness. Это ставит от меня следующий вопрос.

Мы в задании заявили строгую синхронность. Это - правда. By design. Но вот в чем штука.
Зачем нам требования строгой синхронности если у нас все равно нет справедливости в дележе
этого контейнера.

Это вопрос - более философский чем технический.

Есть concurrency. И есть параллелизм . Вот задача умножения матриц - это про параллелизм.
Это - хоршо. Это - good. А задача где много потоков сталкиваются в попытке обновить 1 поле
- это concurrency.

Concurrency - плохо. От нее избавляются обычно. Как? Пересмотром постановки задачи обычно.
Просто если мы уже докатились до ситуации что 10 или 100 потоков обновляют текстовое поле - что-то
у нас уже не в порядке. Поэтому я вот сопротивляюсь самой изначальной идее. Я ищу причины.

В том примере что я привел. У нес есть 10 потоков и некий кумулятивный документ в контейнере мютекса. Если логика позволяет
то мы должны были создать 10 потоков и 10 локальных документов. А по завершению работы всех - спокойно
смёржить все 10 документов в 1. Разумеется если логика позволяет.