memory_order_consume deprecated в C++17

то что мне непонятно, так это почему std::thread такой убогий. Например, не содержит API для очевидных suspend()/resume().

Посмотри на футуры, или, ещё лучше, асинки, и подумой.

Вообще не понятно зачем эта НЁХ была нужна.

Для того, чтобы дожидаться синхронизации из другого треда только того, что доступно по указателю, а не всего, что он в память пытался записать перед атомарной записью указателя. Более того, для arm, например, так и кода сильно меньше получается, потому что он соображает, что при доступе через атомарный указатель по умолчанию нужно доступ к памяти синхронизировать. На arm и IBM power заметные ускорения получались по сравнению с acquire. Правда, компиляторы не факт что умеют оптимизации для consume (в статьях про нее делали код на asm).

почему std::thread такой убогий

Потому что кроссплатформенный.

Потому что кроссплатформенный.

QThread из Qt тоже кроссплатформенный, и поддерживает всё что нужно, и в довесок много всяких банальных приятностей. Почему std::thread такой убогий всё же неясно. Может потому что C++ желает обеспечивать source compability, а на некоторых платформах невозможно приостанавливать треды? Теряюсь в догадках.

По крайней мере отсутствие thread cancellation объясняли проблемами с кроссплатформенностью. И даже где оно есть, оно сделано по-разному, и в Комитете войны на тему API. А Qt - он все-таки на попсовые платформы нацелен.

А когда вы приостанавливаете другой тред, как вы обеспечиваете себе защиту от возможных тупиков и взаимных блокировок внутри приложения?

Для того, чтобы дожидаться синхронизации из другого треда только того, что доступно по указателю

Ок, теперь понятно.

Правда, компиляторы не факт что умеют оптимизации для consume

Как я понял задепрекейтили как раз потому, что факт что не умеют.

Не представляю, как можно сделать thread cancellation в местах кода, который заранее не предполагает, что его могут прервать (т.е. пишешь ты библиотеку, которая работает, например, с базой и должен заранее знать, что поток, в котором она работает, могут внезапно прервать, потому что ее кто-то так решил использовать, и тебе нужно оставить программу в согласованном состоянии). Ну, а если прервать могут в известных местах, то ты и сам это можешь организовать с помощью атомарных флагов и throw, тут поддержка стандарта не нужна.

Не представляю, как можно сделать thread cancellation в местах кода, который заранее не предполагает, что его могут прервать

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

В хаскеле можно инжектить исключения из других тредов асинхронно.

В плюсах тоже можно.

show me the code

http://en.cppreference.com/w/cpp/thread/promise

В одном потоке делаешь set_exception(), а в другом из соответствующего std::future<> получаешь его. Еще есть такая штука: http://en.cppreference.com/w/cpp/error/exception_ptr, но там придется доступ к нему синхронизировать между потоками (mutex'ом, например).

Как я понял задепрекейтили как раз потому, что факт что не умеют.

Смотришь в книгу и видишь фигу. Его не «задепрекейтили», а временно советуют не использовать пока не решат как реализовать фичу более практично.

facepalm.cpp

Я говорил про АСИНХРОННЫЕ исключения. Исключение, вылетающее из future::get() это синхронное исключение, т.к. оно напрямую связано с вызовом этого метода.

Я говорил про АСИНХРОННЫЕ исключения.

Во-первых, подумай, как это реализовано, и, внезапно, исключения станут совсем не такими асинхронными.

Во-вторых, как-то странно слышать про асинхронные исключения, внедренные из другого потока, от чуваков, которые фанатеют от подхода «результат зависит только от входных данных, и никаких побочных эффектов», а тут хрясь, и откуда ни возьмись исключение.

Ну, а, в-третьих, в плюсах возможно сделать все, что есть в хаскеле, а вот с обратным облом.

в плюсах возможно сделать все, что есть в хаскеле

Ржали всем бустом.

не содержит API для очевидных suspend()/resume()

QThread из Qt тоже кроссплатформенный, и поддерживает всё что нужно

Ну давай, кукаретик, покажи нам suspend и resume в QThread.

exec()/quit(). Разница только в названии функций.

exec()/quit(). Разница только в названии функций.

От жеж, ыкспертиза... QThread::exec

Enters the event loop and waits until exit() is called, returning the value that was passed to exit(). The value returned is 0 if exit() is called via quit().

This function is meant to be called from within run(). It is necessary to call this function to start event handling.

QThread::quit

Tells the thread's event loop to exit with return code 0 (success). Equivalent to calling QThread::exit(0).

This function does nothing if the thread does not have an event loop.

Ну и почитайте, что делают pthread_suspend и pthread_resume, найдите пару отличий.

спасибо за цитаты, но я в курсе что они делают. И это будет работать везде. Даже там, где нельзя суспендить треды.

У тебя речь на уровне какого-то дебила:

- Хочу, млять, suspend()!
- А где он есть?
- В Qt!
- Ну и как сделать?
- std::cerr << «Hello world\n»;
- Но это же не suspend(...).
- Я в курсе, зато работает везде, даже где нельзя суспендить треды!

Во-первых, подумай, как это реализовано, и, внезапно, исключения станут совсем не такими асинхронными.

В асинхронные сигналы ты тоже не веришь?

а что с ним не так?

Я говорил про АСИНХРОННЫЕ исключения

В стандартном С++ нет АСИНХРОННЫХ исключений

Это всего лишь инструмент. Понятное дело, что если его использовать неправильно, то это может выйти боком. Но так с любым инструментом. Если бросить исключение, которое никто не собирается ловить, то вообще программа упадёт. И что?

Да не надо вообще использовать это std::thread (ровно как и QThread или как он там). Потому что все-равно никакой кроссплатформености не добьешься. На unix-like, или линуксе - проще всего именно нативное API и юзать. На винде аналогично, причем на винде еще куча моментов касательно COM apartments и т.п., так что одной бездумно написанной оберткой на CreateThread/_beginthreadex - не обойдешься.

Если говорить про серверный код - то мало того, что у разных ОС совершенно разные подходы к тому же IO, но и даже в случае банальных condition variables - все т.н. кроссплатформенные вещи на винде их делали/использовали совершенно неправильно.

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

Не туда воюешь.