Ваш барьер не поможет! Представьте, что поток прочитал флаг и увидел false, далее он хочет заснуть на cv, но в это время другой поток ставит флаг в true и вызывает notify, вот только первый поток не успел встать в очередь cv и пропустит этот notify.
Использовать wait без придиката можно, а вот менять состояние без блока нельзя. Баг именно в этом. Это грозит тем, что потоки ожидающие флага forceExitFromWaiting никогда не проснутся, хотя флаг = true.
Вы не поняли как работают условные переменные. Ваш метод releaseThreadsWaitingItems содержит баг - нельзя менять состояние которое синхронизируется через CV без блока мьютекса. Использовать атомарную переменную бессмысленно.
Я глубоко в ваш код не копал, но выглядит так, что можно из строкового выражения сделать диапозон с input_iterator (генерировать значения на лету для случая преобразователей чисел в строки или ленивых генераторов). Так получится полная совместимость с C++20 ranges и всеми её плюшками. Ну и то что я озвучил выше, на этой основе можно реализовать.
Ещё можно развить идею и не конкатенировать строковое выражение в одну строку а, например, записывать выражение в файл, или дать возможность итерации по такой "строке".
Нет, не перепутаны. Автор пишет про 20 кратное замедление на пустых тасках. Замечание, впрочем, было не про это. Я же говорю про то, что автор заявляет одно, а собирает метрики про совсем другое. Да, измерить производительность тоже интересно, но куда более важно получить метрики про то, для чего это все затевалось.
Вы написали, что преимущество вашего решения это гарантия времени выполнения и предсказуемость, а измерили пропускную способность где полностью проиграли более общему решению.
Ваш барьер не поможет! Представьте, что поток прочитал флаг и увидел false, далее он хочет заснуть на cv, но в это время другой поток ставит флаг в true и вызывает notify, вот только первый поток не успел встать в очередь cv и пропустит этот notify.
При чем тут это?
Использовать wait без придиката можно, а вот менять состояние без блока нельзя. Баг именно в этом. Это грозит тем, что потоки ожидающие флага forceExitFromWaiting никогда не проснутся, хотя флаг = true.
Вы не поняли как работают условные переменные. Ваш метод releaseThreadsWaitingItems содержит баг - нельзя менять состояние которое синхронизируется через CV без блока мьютекса. Использовать атомарную переменную бессмысленно.
Потому что в ином случае все выражение не имеет никакого смысла, оно невалидно, ерунда, чушь, как ещё объяснить - я не знаю.
Что вы мне хотите этим сказать?
Уверенность в том, что X не равен нулю нам даёт тот факт, что X находится в знаменателе. Иначе все выражение не имеет смысла.
Встречались, только при чем тут они?
Что? Если в знаменателе стоит x то он не может быть нулем, следовательно мы всегда можем сокращать на x. Иначе, все выражение не имеет смысла.
Я глубоко в ваш код не копал, но выглядит так, что можно из строкового выражения сделать диапозон с input_iterator (генерировать значения на лету для случая преобразователей чисел в строки или ленивых генераторов). Так получится полная совместимость с C++20 ranges и всеми её плюшками. Ну и то что я озвучил выше, на этой основе можно реализовать.
Ещё можно развить идею и не конкатенировать строковое выражение в одну строку а, например, записывать выражение в файл, или дать возможность итерации по такой "строке".
Поясните, как смещение не будет инвалидировано если удалить элемент расположенный в середине плоского контейнера?
Нет, не перепутаны. Автор пишет про 20 кратное замедление на пустых тасках. Замечание, впрочем, было не про это. Я же говорю про то, что автор заявляет одно, а собирает метрики про совсем другое. Да, измерить производительность тоже интересно, но куда более важно получить метрики про то, для чего это все затевалось.
Вы написали, что преимущество вашего решения это гарантия времени выполнения и предсказуемость, а измерили пропускную способность где полностью проиграли более общему решению.
Вы правы, названия - не мой конёк, но мой репозиторий - это скорее полигон для испытаний, а не что-то готовое. Кроме каналов там еще всего.