RM
Причем довольно подлая ситуация
Size: a a a
2021 July 02
RM
Представим что Thread Pool не является владельцем spsc очереди (то есть, сама очередь лежит где то в другом месте), если очередь уничтожится раньше, чем класс тред пула освободит потоки, то это может привести к хуйне
RM
Нужно как то гарантировать порядок, thread pool уничтожаться должен первым, а уже потом зависимые от него очереди
RM
В принципе, если я сам реализую Job System, то я могу дать такую гарантию, но что если разработчики будут использовать свой тред пул с моей SPSC очередью
RM
В общем, я пришел к выводу, что Job System должна содержать обычную queue очередь откуда будут выниматься таски и кормиться в Thread Pool причем пачками, а Thread Pool должен уже хранить SPSC очередь
RM
Таким образом я могу регулировать переполнение кольцевого буффера в SPSC очереди
RM
Помещая ровно столько элементов, сколько умещается
RM
Должен ли мой тред пул предоставлять возможность менять кол-во потоков - воркеров?
RM
или нет?
RM
Полагаю, что в этом нет необходимости, ведь Job System будет предоставлять функционал для распараллеливания тасков
RM
Почему в этом тред пуле количество ядер получают таким образом?
https://github.com/nvpro-samples/vk_device_generated_cmds/blob/master/threadpool.cpp#L57
https://github.com/nvpro-samples/vk_device_generated_cmds/blob/master/threadpool.cpp#L57
RM
Почему не используется
SYSTEM_INFO sysinfo;
GetSystemInfo(&sysinfo);
numCPU = sysinfo.dwNumberOfProcessors;
AF
hardware_concurrency отстой
VD
++
AF
он может вернуть 0
AF
и непонятно че возвращает вобще
VD
Или количество физ ядер, а не потоков
AF
ну тут хрен его знает че тебе нужно
RM
В смысле?