Как синхронизировать процессы используя только std?

Question

[maaGames]

С синхронизацией потоков никаких вопросов нет, в std куча разного есть. А есть ли std-инструменты для синхронизации процессов? Используя WinAPI можно создать именованные объекты мьютексы и т.д и т.п., но интересует именно стандратное кросс-платформенное решение?
Этого нет в стандартной библиотеке или я просто не умею искать?

UPD: я слишком многого хотел от std, вопрос снят

Answer 1

[rPman]

c++11 и есть стандарт std::thread, std::mutex, std::lock_guard, std::unique_lock, std::condition_variable
типа так:

 std::mutex m;
 // ...
 {
  std::lock_guardstd::mutex lock(m);
  // критическая секция
 }

Comments

[maaGames]

это всё для потоков в пределах одного процесса.

[rPman]

ой, неправильно понял сразу вопрос, в стандарте конечно этого нет, но например есть сторонние библиотеки, та же boost которая как мне кажется, давала много пищи для стандартов - Boost.Interprocess

[maaGames]

rPman, Да со сторними-то понятно. Чисто на Виндоус и WinAPI функций хватало. Просто столько всего в новые стандарты напихали, что мог недоглядеть. Значит и правда нет, а не я невнимательный.

[rPman]

maaGames, по уму подсистема posix которую еще в winnt4 ввели но так на зачаточном уровне и оставили

попросил ии погуглить, он нагуглил это как пример https://github.com/DanielTillett/Simple-Windows-Po... хз как старт попробовать почему нет.

posix это кроссплатформенный стандарт, если бы майкрософт не была такой сволочью и реализовала бы его, мир был бы совсем другим

[maaGames]

rPman, В общем, только сторонние библиотеки и ждём какой-нибудь С++35

[rPman]

maaGames, не думаю что мир будет постоянно подстраиваться под монополисткий булшит майкрософта бесконечно

spoiler

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

если на то пошло, я бы ждал адекватной стандартизации GUI ;) миллион технологий, каждый работает по своему, каждый предлагает свои выкрутасы... дошло до маразма, теперь приложения таскают с собой полноценный веб браузер что бы на html и javascript пилить интерфейсы кроссплатформенно (electron), абстракция на абстракции виртуализацией погоняет и это не остановить

p.s. я бы еще и llvm как стандарт продвигал бы, вот это было бы дело, пиши на каком хочешь языке, компилируй в байткод и запускай везде, с аддекватной песочницей с максимальной производительностью, кросплатформенно, поддерживается ну буквально везде (ладно для микроконтроллеров наверное еще не сделали)

upd. жесть https://github.com/lenticularis39/llvmduino-hardware

[maaGames]

rPman, а при чём тут Майкрософт? Не большой знаток Линуксов, там поток и процесс равнозначны в плане работы std::mutex?

Вот GUI в std крайне маловероятно что когда-то появится. Из boost кое-что тянут в std, но boost то открытый и бесплатный, а вот какой-нибудь Qt бесплатно никто не отдаст. А на что-то, кроме Qt-GUI, сообщество всё-равно не согласится :)

Если хочется кроссплатформенный байткод, то берём Java и пилим что хотим. Там и GUI свой инструментарий кроссплатформенный. Красота.

[rPman]

maaGames, уже забыли как оракл с java вытер о сообщество ноги? спасибо против него был гугл и выкрутились но все равно, теперь в android не java

[maaGames]

rPman, а что там, если не java? GUI свой, но язык-то Java.

[rPman]

maaGames, виртуальная машина там теперь другая, и сам конфликт абсурдный до нельзя

[maaGames]

rPman, Я не очень в курсе. Под андроид только игрушки делал и уровень знаний Java минимален.

[res2001]

maaGames,

Не большой знаток Линуксов, там поток и процесс равнозначны в плане работы std::mutex?

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

Кстати, атомики и барьеры есть в std. Можно положить в разделяемую память атомик. Можно так реализовать простенькую блокировку. Правда на атомике нельзя будет пассивно подождать освобождения ресурса, только активное ожидание - спинлок.

[maaGames]

res2001, не встречал упоминаний, что std::atomic и std::barrier подерживают процессы. Везде тлько про потоки.
Да и разделяемая память это уже API ОС, а не std\C++, а если всё-равно системное что-то испоьзовать, то как бы и изначально есть более удобные решения. Интересновало именно стандартное кроссплатформенное решение, а его нету. Раз нету, будем дальше использовать сторонние библиотеки.

[res2001]

maaGames, атомикам вообще пофигу на процессы и потоки, они работают на уровне физических ядер процессора и им наплевать код какого процесса/потока выполняется в данный момент на разных ядрах. Главное, чтоб в обоих процессах было обращение к одному и тому же атомику, поэтому он должен быть в разделяемой памяти.
А барьерам памяти так и вовсе ничего нигде хранить не надо - это просто ассемблерная инструкция, заставляющая текущее ядро процессора синхронизировать свой кэш с другими ядрами.

Да, разделяемой памяти в std нет.

Answer 2

[Mercury13]

Для чего нужен межпроцессный мьютекс? Для объекта (обычно куска памяти), который не проверяется на уровне системы и в то же время разделён между процессами.

А в стандарте Си++ вообще такие объекты есть? Файлы проверяются. Каналы — насколько помню, нет стандартных, но они тоже проверяются.

UPD3. Syncstream всё же содержит мьютекс, но второе решение — скопить данные в stringstream и сбросить их одной транзакцией — работает.

Comments

[maaGames]

например, когда два приложения пишут в один файл или в одну консоль. Знаю, что это звучит дикой архитектурой, но, если два приложения делают одну большую задачу, то мне удобно писать логи в один файл (одну консоль), а не в два. Можно писать в отдельные файлы с меткой времени, а потом два файла объединить в один, но хочется-то сразу. Межпроцессорным мьютексом синхронизировать запись.

[Mercury13]

maaGames, редактирую основной ответ.

[maaGames]

Mercury13, если бы оно было в стандарте и я бы об этом знал, то стал бы я спрашивать, есть ли такое в стандарте?

Но вот костыль через файл сработает, наверное. Создать пустой файл и открыать его на запись. Тогда второй процесс будет ждать, пока можно будет открыть на запись. Понятно, что можно ещё вебсокеты притянуть или ещё какие-то странные способы. Но мне стало интересно, может в современном С++23(26) уже что-то такое добавили. Особо не слежу за обновлениями.

[Mercury13]

maaGames, syncstream — это Си++20.
https://en.cppreference.com/w/cpp/io/basic_osyncstream

[maaGames]

Mercury13, в описании написано про синхронизацию потоков, а не процессов. Но и для синхронизации потоков полезный класс, спасибо.

[Mercury13]

maaGames, Работает просто и никаких там мьютексов ВООБЩЕ НЕТ. Собирает кучу данных и сваливает её в одну транзакцию. Остальное берёт на себя ОС.

[Mercury13]

maaGames, Потому и написал: можно повторить и руками через ostringstream.

[maaGames]

Mercury13, через строковый буфер ничем не поможет. один поток пишет int=11, второй int=22 и в консоли может оказаться "1212" хоть через буфер, хоть не через буфер. Так что или этот osyncstream или какие-нибудь мьютексы. Но про ввод в консоль это просто для примера.

Допустим, другой жизненный пример. Надо запретить запуск двух экзепляров приложения. Без WinAPI я не могу этого сделать "красиво". То есть можно файл в temp создавать и удалять при закрытии, но это костыли.

[Mercury13]

maaGames, Понимаю, что запуск двух экземпляров — это антипример и годится только с определённым софтом, обычно системным/резидентным. А вообще существуют кроссплатформенные решения?

[maaGames]

Mercury13, Есть же куча библиотек, дающих кросплатформенное решения, абсрагируя от API конкретной ОС. В том же Qt есть QSahredMemory и QSystemSemaprore. Не знаю, QProcess через signal\slot синхронно или асинхроно работает. Всяких сторонних библиотек куча. Интересно было именно есть ли подобный функционал в std. Раз уж они взялись за многопоточность, может и для многопроцессорности что-то делают.

[res2001]

maaGames,

например, когда два приложения пишут в один файл или в одну консоль

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

Можно самому озаботится написанием кроссплатформенных оберток над нужным вам функционалом. Например разделяемая память, именованные каналы или какие-нибудь семафоры - можно довольно легко завернуть в кроссплатформенный API.

[maaGames]

res2001, Совершенно верно. но тут мы уже подключаем или сокеты или ещё какие-то стредства непосредственного обмена собщениями между тремя процессами. С тем же успехом можно и между двумя процессами сообщения передавать синхронизирующие. Интересовало именно простейшая синхрлнизация между процессами, как это возможно для потоков именно средствами std, без сторонних (или самописных) библиотек.

[res2001]

maaGames, Думаю в std вряд ли появятся стредства IPC, т.к. любой язык программирования обычно оперирует в терминах одного приложения, а тут IPC нет в принципе.
Вон даже сокеты не завезли в std, хотя казалось бы - API давно устоялся и примерно похож на разных платформах и есть куча кроссплатформенных реализаций.
Удивительно, что файлы есть :) но тут уж, видимо, отказаться было нельзя - программисты не поймут.