o
Size: a a a
2021 February 24
AP
В джавовском пуле есть одна интересная особенность - там таски создавшие сабтаски могут не тупо стоять и ждать завершения сабтасков в join(), а помочь пулу при вызове join
Хм... прям заинтриговали, сейчас посмотрим на внутренности. Если нет такого - заведём багу
o
@antoshkka Вот в этом видео хорошо обьяснен алгоритм работы, я сам не джавист но искал что-то подобное для решения проблемы. По таймкоду обьясняется как работает join().
https://youtu.be/_2ciDWeeXJQ?t=1140
https://youtu.be/_2ciDWeeXJQ?t=1140
o
Вообще конечно ещё вопрос в том а нужна ли такая сложная логика если можно просто заспавнить новый тредпул на втором уровне параллелизации для сабтасков и положиться на планировщик ОС.
Но тут сразу возникает вопрос - тредпул на сколько потоков создавать? Мы ведь не можем определить достоверно сколько потоков на первом уровне будут нагружены работой.
Но тут сразу возникает вопрос - тредпул на сколько потоков создавать? Мы ведь не можем определить достоверно сколько потоков на первом уровне будут нагружены работой.
AP
@antoshkka Вот в этом видео хорошо обьяснен алгоритм работы, я сам не джавист но искал что-то подобное для решения проблемы. По таймкоду обьясняется как работает join().
https://youtu.be/_2ciDWeeXJQ?t=1140
https://youtu.be/_2ciDWeeXJQ?t=1140
Спасибо, схоронил, поисследую
D
Ну на работе есть масса задач в которой таски имеют непредсказуемую сложность, и есть ситуации когда из тасков можно выделить сабтаски.
Так как на первом уровне параллелизации таски могут иметь сильно разное время выполнения - много ситуаций когда весь алгоритм ждёт завершения одного медленного таска (при 8 потоках например). В такой ситуации можно было бы из этого длинного таска наделать новых сабтасков чтоб ждущие треды в пуле помогли.
Так как на первом уровне параллелизации таски могут иметь сильно разное время выполнения - много ситуаций когда весь алгоритм ждёт завершения одного медленного таска (при 8 потоках например). В такой ситуации можно было бы из этого длинного таска наделать новых сабтасков чтоб ждущие треды в пуле помогли.
TBB реализует что-то похожее :)
https://www.threadingbuildingblocks.org/docs/help/reference/task_scheduler/scheduling_algorithm.html
https://www.threadingbuildingblocks.org/docs/help/reference/task_scheduler/scheduling_algorithm.html
SS
корутины уже появились в компиляторах? а то мой силанг посылает нахрен и пайплайны тоже
EP
корутины уже появились в компиляторах? а то мой силанг посылает нахрен и пайплайны тоже
в мсвц есть, гцц в транке (10 не помню), шланг хз
SS
обидно, но попробую
SS
опять мсвц
AE
а что обидного-то? на Clang на своем сайте про С++20 пишет тонко - Coroutines - Partial. Вы хотите сказать, что под ваши варианты использования не подходит, или что вообще никак?
AE
а какая связь-то у source_location с корутинами? (А давай решать уже решенную задачу - типа C preprocessor , но только еще там подкрутим, потому что нельзя не инновировать)
AE
Связь, с моей т. з., такая, что location-то попроще реализовать, казалось бы. Это пример, что рано ещё на С++20 переходить, в одних компиляторах одно не работает, в других другое, пока все поддержат - уже С++23 будем обсуждать.
да всегда такое было. Еще С++11 - условно у тебя std::thread появился в gcc/clang/msvc, но вот только внутри потока static инициализация потокобезопасная по-разному ими была поддержана и получалось, что в зависимости от кода тебе заходит std::thread или нет
AE
я бы вообще std::source_location последним реализовывал. потому что этот функционал уже сегодня может клиент через С-макросню получить и передавать как строчки