Синхронизация доступа к разделяемой памяти

Когда потоки являются дочерними по отношению к процессу тут все просто - объект мьютекса находится в общей памяти и используя этот объект можно делать mutex.lock() определенной секции а при завершении работы mutex.unlock();

А как синхронизировать доступ к данным shared memory между процессами?
Подозреваю что в таком случае мьютекс нужно хранить разделяемой памяти
Но как конкретно это реализуется плохо представляю
Подскажите пожалуйста кто знает

0

Renji, где-то писал, что какие-то из атомарных операций по стандарту обязаны быть Lock-free. Всё остальное можно проверить специальным интерфейсом, являются ли примитивы, работающие с конкретной переменной, Lock-free

0

Сообщение от sys_beginner Плохо понял что вы имеете ввиду. Разве ему не достаточно иметь доступ к разделяемой памяти?

Теперь как фоновый процесс откатит действия в строчке номер два, если он о них ни сном, ни духом?

0

Сообщение от Evg Моя ситуация. Кто-то начал захватывать мьютекс (который является non-lock-free) и сдох.

Когда я писал навеяно, идеи с фоновым процессом еще не было В целом подумал о проблемах локов более углубленно после твоего поста

Добавлено через 1 минуту

Сообщение от Renji Теперь как фоновый процесс откатит действия в строчке номер два, если он о них ни сном, ни духом?

Данные же в шареде
Разве этот процесс не может сместиться на то смещение в шареде где находятся метаданные и по ним определить где чего откатывать?

Добавлено через 3 минуты
Renji,
Ну или просто использовать атомарный булевный флаг как предлагал (гарантировать последовательность записи данных в память) Evg и перед записью данных делать его фолс а после тру. Если фолс так и остался фолсом - значит данные повреждены

0

Сообщение от sys_beginner Данные же в шареде Разве этот процесс не может сместиться на то смещение в шареде где находятся метаданные и по ним определить где чего откатывать?

Откат требует вернуть в sharedMemory[12] его старое значение. Это старое значение кто-то, где-то сохранил? Нет, мы можем поручить изменяющему шаред-мемори процессу еще и записывать куда-то что он там наизменял. Но процесс то по условию задачи может сбойнуть. А значит может и не сделать бекап. Или сделать, но неправильный.

0

Сообщение от sys_beginner Ну или просто использовать атомарный булевный флаг как предлагал Evg и перед записью данных делать его фолс а после тру

Это две совершенно перпендикулярные проблемы. Ограничивающий флаг (мьютекс) просто обязан быть Lock-free. Без этого ты нормальную систему не построишь никогда. Но это никак не отменяет возможности Dead-lock'ов, возникающих из-за того, что завис процесс, захвативший мьютекс. Так же это никак не отменяет проблемы, что после прибития зависшего процесса данные надо как-то откатить (точнее, как-то надо понять, что и как откатывать)

0

Evg,
Но тем не менее проблема с откатом частично же решается если мы гарантировано знаем что последовательность записи данных в памяти будет одинаковой. Если там фолс - значит такие данные читать нельзя... И вообще не факт что может понадобится откат. Ну похерились данные ну и пофиг. Такое тоже может быть. Главное знать что они повреждены.

Я не говорю что это решит проблему с мертвыми процессами которые захватили примитив но тем не менее хотя бы устранит проблему чтения кривых данных

Возвращаясь к примеру с использованием СУБД так же хочу отметить, что она тоже может "упасть" и тормознуть весь процесс...
Значит надежности все таки нет. Можно конечно создавать процессы "которые следят за процессами которые следят за следящими процессами" но то что они не рухнут все равно не гарантируется....
Наверное надо копать в сторону алгоритмов а не решений за счет вспомогательных процессов/потоков

0

Сообщение от sys_beginner Возвращаясь к примеру с использованием СУБД так же хочу отметить, что она тоже может "упасть" и тормознуть весь процесс...

Может. Но СУБД одна, а процессов много. Вероятность что упадет одна СУБД, куда ниже вероятности что упадет один из сотни процессов. Плюс, СУБД скорее всего отлаживали куда дольше и тщательнее. Чай, не первый год на рынке.

0

Сообщение от Renji Чай, не первый год на рынке.

Согласен
Но все же думаю можно решить как-то на уровне алгоритмов... пока еще не придумал т.к новичок в таких вопросах, может со временем и найду золотую середину

0

Сообщение от sys_beginner Но тем не менее проблема с откатом частично же решается если мы гарантировано знаем что последовательность записи данных в памяти будет одинаковой. Если там фолс - значит такие данные читать нельзя... И вообще не факт что может понадобится откат. Ну похерились данные ну и пофиг. Такое тоже может быть. Главное знать что они повреждены.

Скажем так, что и как решается и может ли вообще решаться - знаешь только ты, как автор софта. Это же свойство конкретной задачи, а не что-то общее. Если каждый процесс захватывает семафор, переписывает миллион байтов данных (которые должны быть согласованы), то в случае зависания процесса никто уже не сможет сказать, сколько байт он успел переписать

0

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

Сообщение от Evg Для этого и придумали способ, как это явно указать - добавив класс атомарных операций с семантикой, обеспечивающей требуемую упорядоченность.

На самом деле все не совсем так. Решить данную проблему можно и без таких классов, забегая вперед отмечу что для решения этой проблемы используются барьеры памяти, а все классы которые дают гарантии определенного "ордеринга" лишь реализуют эти барьеры. Применение этих барьеров сильно зависит от тех гарантий memory ordering, которые предоставляет процессор выполняющий наш программный код. Например, если нащ код исполняется в процессорах у которых строгий memory ordering, барьеры памяти использовать не нужно, потому что последовательность выполнения процессором указанных в коде операций будут в том же порядке что гарантируется самим процессором. Но жесткие гарантии как правило мешают оптимизации и соответственно такие процессоры работают медленнее чем те, у которых гарантии в отношении memory ordering слабее. Семантика relaxed о которой ты говорил как правило не обеспечивает вообще никаких гарантий последовательности доступа к данным.

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

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

Процесс синхронизации кешей
Когда другое ядро получает сообщение о том, что его кеш относительно измененной переменной устарел, оно не сразу обновляет у себя в кеше это значение а помещает/может поместить его в специальную очередь под названием invalidate queue, которую возможно разгребет чуть позже так как сейчас у этого ядра есть более важные дела. При этом ядро изменившее значение переменной тоже не сразу кладет свои данные в свой кеш. Что бы положить эти данные в свой кеш это ядро должно убедиться в том, что все ядра которым он отправил сообщение об инвалидации своих значений успешно приняли это сообщение. Что бы не простаивать в ожидании подтверждения от других ядер что они получили его сообщение, записавшее значение ядро кладет его в свою очередь на запись в кеш, которая называется store buffer.

Чтение потоками (ядрами) данных
Возвращаемся к примеру
Изначально я предполагал, что ready = true; гарантировано будет записано в память после data = 100;
Но тут возникает вопрос. О какой памяти вообще идет речь? А речь идет именно о кеше читающего эти данные потока(ядра), то есть:
Так вот. Это действительно может быть именно так и без всяких барьеров, в зависимоти от гарантий которые предоставляет процессор в отношении своей модели памяти.
Но если процессор таких гарантий не предоставляет, программисту нужно позаботиться об этом самостоятельно.
Почему же на самом деле читающий данные поток может не иметь в наличи data не смотря на то, что ready все таки true?
Как уже упомяналось выше, может возникнуть ситуация когда читающий поток получит сообщение на инвалидацию данных переменной data, но применит эти изменения к своему кешу чуть позже.
На момент чтения data, это "чуть позже" может еще не наступить, и у читающего потока на руках будут старые данные а не свежие, которые появятся после выполнения invalidate queue для синхронизации кешей процессоров.

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

Например, для того, что бы гарантировано знать, что при выполнении ready = true;, данные data = 100; уже сидят в кеш линии текущего ядра, нужно применить барьер StoreStore который гарантирует следующее:
Читающий поток в свою очередь должен применть LoadLoad барьер который гарантирует, что все операции чтения до барьера будут сделаны ДО всех операций чтения ПОСЛЕ барьера. То есть читающий псевдокод должен быть таким:
Это приведет к выполнению изменений которые находятся в Invalidate queue читающего потока и таким образом читающий поток запишет себе в кеш данные которые изменил пишуший поток.
В итоге мы получаем такую вот согласованность. Эти барьеры применяются только к тому ядру, на котором выполняется код. Соответственно под каждый код - свои барьеры, если они нужны.
Некоторые детали были опущены специально, что бы упростить изложение этой весьма непростой темы.

Добавлено через 19 минут
...

0

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

Разумеется, класс является не более чем системо-независимой обёрткой над системо-зависимой реализацией. GNU'шники то же самое делали в Си в виде builtin'ов https://gcc.gnu.org/onlinedocs... ltins.html, а в Си++ эти самые обёртки реализовали через builtin'ы. Всё это ради того, чтобы не нужно было возиться с написанием, грубо говоря, ассемблерных вставок под каждую платформу

Сообщение от sys_beginner Семантика relaxed о которой ты говорил как правило не обеспечивает вообще никаких гарантий последовательности доступа к данным

Да, там я ошибся (я потом отписал правильный вариант). Она кроме атомарности вроде бы как не обеспечивает вообще ничего

Сообщение от sys_beginner Например, для того, что бы гарантировано знать, что при выполнении ready = true;, данные data = 100; уже сидят в кеш линии текущего ядра, нужно применить барьер StoreStore который гарантирует следующее:

Такое же свойство включает в себя семантика memory_order_release в классе атомарных операций. Я не знаю, что такое StoreStoreBarrier, но если это какой-то интерфейс, то он явно непереносимый. В то время как var.store(value,std::memory_order_releas e) - это переносимая реализация

0

Сообщение от Evg Я не знаю, что такое StoreStoreBarrier, но если это какой-то интерфейс, то он явно непереносимый.

Это был просто псевдокод с пояснением что должен уметь делать барьер и где он должен находится что бы получилось то что нам нужно. Если говорить о С++, что бы применить тот или иной барьер вызывается std::atomic_thread_fence и туда передается уже нужный нам барьер, один из enum-а std::memory_order_*

0

Сообщение от Evg Я не знаю, что такое StoreStoreBarrier, но если это какой-то интерфейс, то он явно непереносимый. В то время как var.store(value,std::memory_order_releas e) - это переносимая реализация

Ну так есть переносимые барьеры в C++ - std::atomic_thread_fence(/*memory order*/)

0

std::atomic_thread_fence - это слишком консервативное решение, которое надёжно "барьеризует" всё, что можно. А вот запись с std::memory_order_release - это частный случай, который барьеризует только то, что реально надо. И этот вариант работает быстрее, чем std::atomic_thread_fence. Но при этом программист должен понимать, что он делает (т.е. чётко понимать значение всех семантик и как они работают совместно друг с другом). В посте #37 приведён один из вариантов использования. Когда атомарная переменная используется в качестве семафора для критической секции, то запись значения "занято" нужно делать с семантикой "acquire", а запись значения "свободно" - с семантикой "release". Собственно при такой работе мы и получим нужные синхронизации кэшей. Конечно же всё это можно сделать и через std::atomic_thread_fence, но в общем случае это будет работать более медленно (но конкретно на intel'е разницы скорее всего не будет)

Добавлено через 2 минуты
Хотя я всё это описывал из общих соображений, никак не связанных конкретно с классом std::atomic. Я никогда с этими классами не работал, просто предполагаю, что они должны работать именно так (было бы совсем нелогично, если бы они работали как-то по другому)

0