RM
Не в этом дело
Size: a a a
2021 July 04
RM
Два потока в любом случае конфликтуют
RM
Поэтому логичней будет использовать потоки правильно
RM
Когда один поток занят своими делами, то другой должен выполнять задачи
RM
Зависит от того кто пишет
RM
Основной поток большую часть времени будет занят выполнением другой задачи
RM
Я не знаю насколько эта идея будет эффективной, но она должна быть быстрее
RM
Идея та же N потоков в тред пуле ждут notify_one
RM
Основной поток занимается вставкой задач
RM
Когда разработчик добавляет задачу чтоб выполнить ее асинхронно, то эту задачу нужно добавить в queue (простая очередь внутри нашего класса)
RM
Потом когда у нас вызывается метод Update мы должны сигнализировать о том, что основной поток вставляет элементы
RM
Тут немного спорный момент конечно
RM
В том плане, что должен ли основной поток каждый тик добавлять задачи из своей queue в очередь задач тред пула
RM
Я думаю, логичней было бы передавать всю очередь в тред пул и ждать от него сигнала
RM
Когда тред пул завершит все задачи, что ему дали, он сигналит
RM
и основной поток когда вновь будет вызывать тик увидит что работа выполнена и отдаст новую очередь
RM
Эту идею можно было бы сделать более эффективной, если бы мы разделили каждый поток
RM
Чтоб каждый поток имел свою очередь
RM
И наш основной поток будет сигнализировать каждому из них, разделяя задачи равномерно
RM
Так мы добьемся параллелизма