Boost thread - ограниченное количество потоков?, непонятное ограничение, не связанное с ресурсами системы Опции

[ViGOur]

Я для себя пришёл к выводу, что поддерживать КП без очень, очень веских на то причин - жутко затратная штука. Оттестил там - здесь отвалилось. Оттестил здесь - там отвалилось.

Не согласен. Если придерживаться стандартов и не привязываться к API, то все будет отлично. Если привязываться, то сложности в основном в планировании как и что будет работь.

Мне кажется, здесь что-то не так в архитектуре приложения. Не лучше ли было бы использовать такие концепции, как "пул потоков" и "задание"? То есть, создается относительно небольшой пул рабочих потоков (размером, например, 2 * количество процессоров),

Как я понял у Iron Bug множество независимых железок, которые должны работать индивидуально и не запороть работу других.

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

Iron Bug поправь меня если я тебя не правильно понял.

[Litkevich Yuriy]

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

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

[Гость_Stranger_*]

Iron Bug, вот я прочел и так и не понял: зачем все-таки плодить такое колоссальное количество потоков? Тем более, что 99.9% постоянно будут в состоянии ожидания, а когда же им дадут чуток поработать....
Мне кажется, здесь что-то не так в архитектуре приложения. Не лучше ли было бы использовать такие концепции, как "пул потоков" и "задание"? То есть, создается относительно небольшой пул рабочих потоков (размером, например, 2 * количество процессоров), и - баааальшая такая очередь заданий, которую они будут трудолюбиво разгребать. Как-то так.......
А при 2000 потоков они в основном будут бесполезно кушать ресурсы процесса, не успевая сделать ничего полезного.
Нет?