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

[Iron Bug]

добрый день всем.
вот, может, кто сталкивался с подобной проблемой:
использую библиотеку thread boost'а для кроссплатформенного программирования. до недавего времени всё было замечательно, но тут возникло одно неприятное открытие:
оказалось, что буст почему-то ограничивает возможное количество потоков. а именно: после создания какого-то числа работающих потоков создание очередного потока проваливается с исключением boost::thread_resource_error и до уменьшения количества работающих потоков создание нового потока невозможно (каждый раз выпадает это исключение). причём это максимальное число потоков не зависит от реальных ресурсов системы, либо зависимость мне непонятна.
для проверки была написана маленькая программа - генератор потоков. потоки просто создаются, спят какое-то время, потом завершаются. потоки пустые, мелкие - то есть, памяти теоретически должно хватать. при этом задавалось разное время жизни потоков и разное количество потоков. результаты по подсчёту количества потоков всегда одинаковы, независимо от времени жизни каждого потока. это число каким-то загадочным образом зависит от машины, но, по видимому, не зависит от количества свободной памяти процесса и системы.
из опытов получилась такая странная картина: дома стоит машина под линюксом, 4 гектара памяти, своп вообще не используется - опытным путём получен предел в 382 потока, на работе машина под вендой, 1 гектар памяти, предел - 2024 потока. увеличение-уменьшение количества других процессов в системе никак не влияет.
откуда берутся такие странные цифры? может, есть возможность определить каким-то образом, как распределять ресурсы, чтобы потоков было больше? по работе необходима возможность одновоеменного выполнения очень большого и заранее неопределённого количества потоков в риал-тайме (пул потоков как бы не подходит по замыслу задачи). непонятно, откуда исходит это ограничение и как с ним бороться (если это вообще возможно).

[ViGOur]

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

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

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

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

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

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