Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
|
|
|
Что под капотом у std::mutex
|
|||
|---|---|---|---|
|
#18+
бабушкин зайчик Dima T пропущено... Для того и блокируют, чтобы во время записи никто не мог читать. это только mutex делает или любая блокировка? Любая, но мутекс в т.ч. для этих целей изобрели. бабушкин зайчик разве нет раздельных блокировок на запись и чтение? Ты принципов потокобезопасности похоже не понимаешь. Допустим есть табло, на нем написано слово ПАПА, писатель начинает побуквенно менять на слово ЖОРА, две буквы сменил, отвернулся третью взять, а тут читатель решил прочитать. Догадался что он прочитает ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2021, 07:13 |
|
||
|
Что под капотом у std::mutex
|
|||
|---|---|---|---|
|
#18+
бабушкин зайчик я ещё размышляю о том mutex или не mutex... вполне можно и обойтись)) - пишите код в одном потоке. Не переживайте, компьютер успеет)) - не расшаривайте один ресурс на несколько потоков сразу - дробите или копируйте ресурс - "высокий параллелизм - это компромиссы" авторТак чем же придется пожертвовать при использовании стратегии высокого параллелизма? В зависимости от дизайна приложения, вам, возможно, придется выполнять операции чтения вне транзакций, даже когда операция чтения выполняется в целях изменения данных. «Минуточку!» – скажете вы: «Так нельзя – это может кончиться изменением данных, которые уже были изменены после их чтения!» Это правильное замечание, и заодно – это точка старта игры в компромиссы. При этой стратегии, поскольку вы не удерживаете блокировок данных на чтение, шансы на получение исключений, говорящих об устаревших данных, при операциях обновления увеличивается. Однако, как и в случае корабля Vasa, придется выбирать, какие характеристики важнее: надежная, пуленепробиваемая транзакционная стратегия (типа стратегии слоя API) или высокий параллелизм и пропускная способность. В ситуациях с большим количеством параллельных обращений очень трудно обеспечить и то, и другое, а если попытаться достичь этого, может оказаться, что приложение не делает хорошо ни того, ни другого. http://www.k-press.ru/cs/2009/3/ts/ts.asp ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2021, 10:38 |
|
||
|
Что под капотом у std::mutex
|
|||
|---|---|---|---|
|
#18+
Dima T Ты принципов потокобезопасности похоже не понимаешь. Допустим есть табло, на нем написано слово ПАПА, писатель начинает побуквенно менять на слово ЖОРА, две буквы сменил, отвернулся третью взять, а тут читатель решил прочитать. Догадался что он прочитает ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2021, 10:42 |
|
||
|
Что под капотом у std::mutex
|
|||
|---|---|---|---|
|
#18+
rdb_dev, "Для того чтобы судить о качестве приготовленной яичницы - необязательно уметь нести яйца" (с) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2021, 10:54 |
|
||
|
Что под капотом у std::mutex
|
|||
|---|---|---|---|
|
#18+
rdb_dev Dima T Ты принципов потокобезопасности похоже не понимаешь. Допустим есть табло, на нем написано слово ПАПА, писатель начинает побуквенно менять на слово ЖОРА, две буквы сменил, отвернулся третью взять, а тут читатель решил прочитать. Догадался что он прочитает ? Недавно смотрел доклад одного господина про Erlang и perfomance. И он упоминал о том что даже atomic (CAS) зависит от количества ядер (кешей). Грубо говоря ты докидываешь в железо больше параллелизма, покупаешь 4 процессора по 16 и 24 ядер а работа CAS при этом не улучшается а ухудшается за счет необходимости проверять большее число физических устройств кешей чтобы гарантировать проверку-установку. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2021, 11:27 |
|
||
|
Что под капотом у std::mutex
|
|||
|---|---|---|---|
|
#18+
PetroNotC Sharp rdb_dev, "Для того чтобы судить о качестве приготовленной яичницы - необязательно уметь нести яйца" (с) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2021, 12:12 |
|
||
|
Что под капотом у std::mutex
|
|||
|---|---|---|---|
|
#18+
Dima T бабушкин зайчик разве нет раздельных блокировок на запись и чтение? Ты принципов потокобезопасности похоже не понимаешь. Допустим есть табло, на нем написано слово ПАПА, писатель начинает побуквенно менять на слово ЖОРА, две буквы сменил, отвернулся третью взять, а тут читатель решил прочитать. Догадался что он прочитает ? data race, race condition, false sharing... Кое-что понимаю. DimaTВсе классы-контейнеры из std:: НЕпотокобезопасные, поэтому при многопоточной работе с ними надо дополнительно прописывать синхронизацию доступа. Это сложно... А если просто под mutex засунуть запись в такой контейнер, то никто не сможет из него читать. Говорят, корутины решают все проблемы асинхронности и НЕблокирующей синхронизации? rdb_dev Чтобы понимать принципы потокобезопасности, надо иметь представление о когерентности кэша процессора и атомарных инструкций процессора работы с памятью на целевой платформе. L1 обычно НЕ шарится, L2 шарится на 2 ядра, L3 шарится на 4... Кое-что понимаю. PetroNotC Sharp - пишите код в одном потоке. Не переживайте, компьютер успеет)) никогда он не успеет столько же прочитать, как в 20 потоков PetroNotC Sharp - не расшаривайте один ресурс на несколько потоков сразу И как тогда читать в несколько потоков? PetroNotC Sharp - дробите или копируйте ресурс и что получится? В одном потоке будут писать в один ресурс, в другом читать из других ресурсов... А дальше что? А смысл? А блокировка чем хуже? mayton Недавно смотрел доклад одного господина про Erlang и perfomance. И он упоминал о том что даже atomic (CAS) зависит от количества ядер (кешей). Грубо говоря ты докидываешь в железо больше параллелизма, покупаешь 4 процессора по 16 и 24 ядер а работа CAS при этом не улучшается а ухудшается за счет необходимости проверять большее число физических устройств кешей чтобы гарантировать проверку-установку. Говорят, что каждому потоку надо выделять отдельный проц (или даже на процессы побить и кидать запросы в пул)... По мне так это самое идеальное для сегодняшнего железа. Другой вариант - микросервисы, где каждому сервису - свой компьютер. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2021, 12:20 |
|
||
|
Что под капотом у std::mutex
|
|||
|---|---|---|---|
|
#18+
mayton, влияет не столько увеличение количества ядер, сколько увеличение количества DSM/NUMA узлов - процессорных юнитов, потому как взаимодействие между ядром одного процессора с памятью, адресуемой другим процессором, происходит по специальному MESI протоколу, например Intel QuickPath, который является "бутылочным горлышком". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2021, 12:25 |
|
||
|
Что под капотом у std::mutex
|
|||
|---|---|---|---|
|
#18+
бабушкин зайчик rdb_dev Чтобы понимать принципы потокобезопасности, надо иметь представление о когерентности кэша процессора и атомарных инструкций процессора работы с памятью на целевой платформе. L1 обычно НЕ шарится, L2 шарится на 2 ядра, L3 шарится на 4... Кое-что понимаю. Нужно понимать, что такое cacheline, как они работают и как работают атомарные инструкции работы с ОЗУ, к примеру, такие как "xchg" или "lock cmpxchg". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2021, 12:29 |
|
||
|
Что под капотом у std::mutex
|
|||
|---|---|---|---|
|
#18+
rdb_dev, кстати, недавно проскакивала смежная тема 22370268 . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2021, 12:40 |
|
||
|
Что под капотом у std::mutex
|
|||
|---|---|---|---|
|
#18+
rdb_dev mayton, влияет не столько увеличение количества ядер, сколько увеличение количества DSM/NUMA узлов - процессорных юнитов, потому как взаимодействие между ядром одного процессора с памятью, адресуемой другим процессором, происходит по специальному MESI протоколу, например Intel QuickPath, который является "бутылочным горлышком". Тогда надо кластеризовать процесcы вокруг узлов. Тоесть брать "ручное управление" вместо планировщика. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2021, 12:41 |
|
||
|
Что под капотом у std::mutex
|
|||
|---|---|---|---|
|
#18+
бабушкин зайчик DimaTВсе классы-контейнеры из std:: НЕпотокобезопасные, поэтому при многопоточной работе с ними надо дополнительно прописывать синхронизацию доступа. Это сложно... А если просто под mutex засунуть запись в такой контейнер, то никто не сможет из него читать. Надо засовывать под мьютекс или другую блокировку. И не только запись, а любое обращение к контейнеру. Чудес не бывает. Чтобы могли читать - пишуший не должен блокировать навечно, только минимально необходимое для записи, в остальное время читатели пусть читают. бабушкин зайчик Говорят, корутины решают все проблемы асинхронности и НЕблокирующей синхронизации? Кто говорит? Неблокирующая синхронизация строится на атомарных операциях. Есть потокобезопасные контейнеры построенные на этих принципах, но к std:: это не относится. Можешь почитать разработчика таких контейнеров https://habr.com/ru/users/khizmax/posts/ По сути неблокирующая синхронизация все равно блокирующая, только на уровне проца. Одно ядро запрещает другим читать некоторый участок памяти и производит его изменение, если в этот момент другие ядра попытаются туда писать/читать, то будут приостановлены до завершения работы ядра захватившего память. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2021, 12:43 |
|
||
|
Что под капотом у std::mutex
|
|||
|---|---|---|---|
|
#18+
бабушкин зайчик Говорят, корутины решают все проблемы асинхронности и НЕблокирующей синхронизации? Корутин - это просто функция с состоянием которую можно много раз вызывать. И все. Сам по себе корутин ничего не решает. Решает наверное архитектура акторов которые по смыслу - корутины читающие очередь сообщений. Но мне кажется что в этом топике - уж слишком контр-продуктивно перескакивать на эту тему. Это знаетели... начали пить за здравие - и закончили "за упокой души". Уж лучше останемся в рамках мьютекса или критической секции. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2021, 12:50 |
|
||
|
Что под капотом у std::mutex
|
|||
|---|---|---|---|
|
#18+
бабушкин зайчик никогда он не успеет столько же прочитать, как в 20 потоков Ну прочитал Войну и Мир за 3 сек. А дальше то что? Горд очень этим? Бизнесу не надо читать на скорость (с) бабушкин зайчик и что получится? В одном потоке будут писать в один ресурс, в другом читать из других ресурсов... А дальше что? А смысл? А блокировка чем хуже? Статью мою по ссылке про ПАРАЛЛЕЛИЗМ прочитал? К компромиссам готов? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2021, 12:55 |
|
||
|
Что под капотом у std::mutex
|
|||
|---|---|---|---|
|
#18+
бабушкин зайчик, блокировки в веб проектах это плохой стиль архитектуры. Верить или нет - твоё дело. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2021, 12:59 |
|
||
|
Что под капотом у std::mutex
|
|||
|---|---|---|---|
|
#18+
PetroNotC Sharpблокировки в веб проектах это плохой стиль архитектуры. Уэб-проекты сами по себе это квинтэссенция плохой архитектуры, блокировками их уже не испортишь. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2021, 13:12 |
|
||
|
Что под капотом у std::mutex
|
|||
|---|---|---|---|
|
#18+
Dima T Надо засовывать под мьютекс или другую блокировку. И не только запись, а любое обращение к контейнеру. Чудес не бывает. А зачем любое? Если поток читает, а в этот момент другой пишет И блокирует, то первый же не сможет читать? Он будет перечитывать после разблокировки или что произойдёт? mayton Корутин - это просто функция с состоянием которую можно много раз вызывать. И все. так это обычная ф-я со static внутри ? итого, на опыте, как задачу то решать? бабушкин зайчик я ещё размышляю о том mutex или не mutex... ну есть 2 направления: чтение и запись в чтении ф-и для чтения в записи ф-и для записи их может быть много... запросов может быть много... за один запрос может быть затронуто несколько ф-й вопрос в том, как блокировать: бабушкин зайчик 1. заблокировать весь пишущий запрос 2. заблокировать в пишущем запросе все пишущие ф-и (т.е. вручную каждую отблочить) и как быть с чтением во время записи? вообще не блокировать и всё в один поток? корутинами? блокировать куски контейнера во время записи? выдать каждому контейнеру по микросервису и отдельный процесс? (так то записи будет гораздо меньше, чем чтения, но запись ведь всегда можно нагрузить вручную...) PetroNotC Sharp Бизнесу не надо читать на скорость (с) ну да, бизнесу надо, чтобы всё висело, а клиент ждал каждую операцию 10+ секунд ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2021, 13:15 |
|
||
|
Что под капотом у std::mutex
|
|||
|---|---|---|---|
|
#18+
rdb_dev бабушкин зайчик пропущено... L1 обычно НЕ шарится, L2 шарится на 2 ядра, L3 шарится на 4... Кое-что понимаю. Нужно понимать, что такое cacheline, как они работают и как работают атомарные инструкции работы с ОЗУ, к примеру, такие как "xchg" или "lock cmpxchg". авторПри написании программы, которой требуется частый доступ к данным или их части, стоит помнить, что производительность будет выше, если запрашиваемые данные помещаются в cache-line — блок памяти, целиком читаемый процессором при доступе к адресу в нем. На 64-битной машине он обычно занимает 64 байта, на других платформах — обычно 32 байта. Группировка связанных данных не только улучшает читаемость, но и способствует локализации данных в кэше. Это дополнительная причина реорганизовывать структуры с учетом особенностей доступа к данным в вашей программе. Если в вашем коде есть конкурентный (concurrent) доступ к данным, появляется третья проблема: «cache line bouncing». Для минимизации трафика в шине следует располагать данные так, чтобы чтение из одного кэша и запись в другой производились с меньшим промежутком. Да, это противоречит предыдущему замечанию, однако многопоточный код — это всегда сложно. Оптимизация многопоточного кода — тема, заслуживающая отдельной большой статьи. Все, что я могу здесь сказать, такая проблема существует. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2021, 13:22 |
|
||
|
Что под капотом у std::mutex
|
|||
|---|---|---|---|
|
#18+
mayton Тогда надо кластеризовать процесcы вокруг узлов. Тоесть брать "ручное управление" вместо планировщика. Поэтому операционки, как правило, выкидывают с user-space соответствующие функции API, позволяющие получать информацию о кол-ве ядер, процессоров и NUMA узлов, а также задавать предпочтительный логический процессор (ядро). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2021, 13:23 |
|
||
|
Что под капотом у std::mutex
|
|||
|---|---|---|---|
|
#18+
бабушкин зайчик Dima T Надо засовывать под мьютекс или другую блокировку. И не только запись, а любое обращение к контейнеру. Чудес не бывает. А зачем любое? Если поток читает, а в этот момент другой пишет И блокирует, то первый же не сможет читать? Он будет перечитывать после разблокировки или что произойдёт? Сначала читатель дочитывает, писатель в это время ожидает блокировки, когда читатель дочитал, писатель блокирует и пишет, читатель при необходимости прочитать ждет пока писатель закончит. В один момент времени с контейнером работает только один поток, если в этот момент другой поток хочет обратиться к контейнеру, то он останавливается и ждет пока первый закончит и снимет блокировку. Ты вроде написал что понял о чем речь 22388567 , но похоже что нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2021, 13:26 |
|
||
|
Что под капотом у std::mutex
|
|||
|---|---|---|---|
|
#18+
бабушкин зайчик, уже лучше! Осталось только ознакомиться с работой инструкций: prefetch, clflush, mfence, sfence и lfence :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2021, 13:27 |
|
||
|
Что под капотом у std::mutex
|
|||
|---|---|---|---|
|
#18+
Dima TТы вроде написал что понял о чем речь, но похоже что нет. А уж что будет когда он доберётся до множественных читателей, которым хочется разрешить читать одновременно... Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2021, 13:30 |
|
||
|
Что под капотом у std::mutex
|
|||
|---|---|---|---|
|
#18+
бабушкин зайчик ну да, бизнесу надо, чтобы всё висело, а клиент ждал каждую операцию 10+ секунд - поток с ГУИ без длительных операций. Теперь скажи - как чтение Война и Мир за 3 сек в доп потоке потребовали блокировки? )))) Какие то студенческие ТЗ для размышлений. Нам надо вас уговаривать на блокировки? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2021, 13:30 |
|
||
|
Что под капотом у std::mutex
|
|||
|---|---|---|---|
|
#18+
rdb_dev Иными словами - не обязательно изучать микросхематехнику и проектировать процессоры? :) Достаточно понимать про "атомарность" и "изменчивость" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2021, 13:36 |
|
||
|
Что под капотом у std::mutex
|
|||
|---|---|---|---|
|
#18+
Dima T бабушкин зайчик пропущено... А зачем любое? Если поток читает, а в этот момент другой пишет И блокирует, то первый же не сможет читать? Он будет перечитывать после разблокировки или что произойдёт? Сначала читатель дочитывает, писатель в это время ожидает блокировки, когда читатель дочитал, писатель блокирует и пишет, читатель при необходимости прочитать ждет пока писатель закончит. В один момент времени с контейнером работает только один поток, если в этот момент другой поток хочет обратиться к контейнеру, то он останавливается и ждет пока первый закончит и снимет блокировку. Ты вроде написал что понял о чем речь 22388567 , но похоже что нет. дело в том, что везде пишут про блокировки на запись... а чтение блокировать якобы НЕ надо (в т.ч. и мультичтение вообще блокировать НЕ надо) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2021, 13:38 |
|
||
|
|
Start [/forum/topic.php?fid=57&msg=40107235&tid=2017163]: |
0ms |
get settings: |
19ms |
get forum list: |
6ms |
check forum access: |
1ms |
check topic access: |
1ms |
track hit: |
28ms |
get topic data: |
5ms |
get forum data: |
1ms |
get page messages: |
526ms |
get tp. blocked users: |
1ms |
| others: | 158ms |
| total: | 746ms |
| 0 / 0 |
